Есть давнишнее исследование британских ученых о количестве часов потраченных офисным работником непосредственно на работу - 2 часа 45 минут в среднем. Ссыль не приведу, ищите сами. Так что, ваши подопечные явно не договаривают.
Какая разница в производительности между двумя потоками с асинхронным поиском и одним потоком, стоит ли игра свеч? Дублирование больших данных выглядит как сомнительный подход, не проще ли использовать IndexedDB для этого?
Все основные умеют. Разница между загрузкой html и парсинга в dom и загрузкой js и создания dom дерева минимальна. Все зависит от размера и сложности библиотеки которая этим занимается. Fusor маленький и быстрый, поэтому разница по скорости с ssr будет не заметна.
В основном согласен с вами. Единственное что бы хотелось добавить, что использование библиотек - это хорошо и правильно. Если только эти библиотеки решают одну конкретную задачу и решают ее хорошо ("Do one thing and do it well").
Оправдали и продолжают развиваться. Яблоко должно страдать за то что тормозят инновации в угоду наживы. Их уже Евросоюз дожимает на установку сторонних броузеров. И пользователям было бы морально их бойкотировать за это.
В хроме на анроиде нормальная установка, а на десктопе у меня около 40 приложений PWA. Я знаете ли не люблю проприетерное ПО которое может делать что-то плохое на моем компе. А вот в безопасном броузерном сэндбоксе - пожалуйста!
Всё когда-то было ново и неизведанно. И это не повод чтобы отказываться от прогресса. Если ваше приложение действительно нужно людям, то они в лепёшку разобьются чтобы его установить.
Оба - фреймворки. Оба средней производительности, "good enough", заточены под все и ничего. SSR становится не актуальным, поисковики спокойно парсят CSR/SPA. Мобильная разработка становится не актуальной при развитии PWA. JSX это просто способ вызова функций, что гораздо лучше чем новый кастомный синтаксис для Javascript. Если нужен контроль, простота и производительность, то лучше так фронтэнд готовить.
У этих ребят у самих "корона" которую не мешало бы сбить, для их же блага. Интервью не мешало бы записывать, и потом делать ревью хотябы одним-двумя людьми. А то может там самовлюбленный школьник сидит, натасканный на олимпиадных задачках, заворачивающий хороших кандидатов.
Нормальное формирование переходов это хорошая практика вэб-разработки. Вставить ссылки на переходы это совсем простая задача.
А вот в серверным код подмешивать клентский, также мы делали во времена вэб 1.0 на ПХП - это и усложнение серверного кода, и усложнение клиентского кода, и усложнение всего приложения в целом, и усложнение разработки и АПИ. Это и дополнительная нагрузка на сервер, это работает медленнее чем забрать оптимизированный клиент из CDN, это всё остально что еще не учел, что из этого вытекает...
Может эта проблема, которую мы сами себе создаем, а потом героически пытаемся решить? Неужели нельзя правильно ссылки сделать?
А вы уверены что у вас все переходы сделаны правильно через ссылки как описано выше? Также, что они присутствуют в DOM? Так как в при скрытии менюшки, это типичная практика, они оттуда удаляются. А Гугл не будет кликать по менюшке чтобы ее открыть.
По виду вы там использовали Material-UI. Это тяжелый и медленный монстр, в котором скорей всего вышеописанное сделано через одно место)
Но у вас всегда остается возможность сделать sitemap.
Видимо имелось в виду что не будет кликать по не семантическим навигационным элементам. Например если мы на div повесим событие onclick то Гугл не может знать, это переход или изменение темы CSS. Поэтому и привел что написано дальше, правильно формировать переходы по ссылкам <a href="..., в том числе и для табов.
Плюсом идет отдельная штука как sitemap, которая параллельно может решить эту проблему.
Вообще не вижу смысла спорить дальше, потому что доказано уже на практике, что SPA без SSR отлично индексируются.
Думаю нам пора уже пересмотреть устаревшие (с 2018 года) догматы.
Internal linking and URL structure: Create a clear, logical internal linking structure. Implement important navigational links as real HTML anchor tags (<a href="...">) rather than JavaScript-based navigation. This approach aids both user navigation and search engine crawling efficiency while potentially reducing rendering delays.
Sitemaps:Use and regularly update sitemaps. For large sites or those with frequent updates, use the <lastmod> tag in XML sitemaps to guide Google's crawling and indexing processes. Remember to update the <lastmod> only when a significant content update occurs.
Вот не люблю я не свободное ПО. Поэтому устанавливаю его только как PWA, в безопасном броузерном сэндбоксе. Чего и вам советую.
Кстати обратите внимание на 2 версии VSCode (личная и рабочая) установленных тоже как вэб приложения. Это работает в докере и локальном браузере, избегая загрузки электрона.
Есть давнишнее исследование британских ученых о количестве часов потраченных офисным работником непосредственно на работу - 2 часа 45 минут в среднем. Ссыль не приведу, ищите сами. Так что, ваши подопечные явно не договаривают.
Ого, прямо мой опыт, только я пришел к JavaScript/Typescript и таким же выводам, спасибо!
Если между 2 антеннами появилось препятствие,
то нужно поставить третью антенну в обход, начать изобретать чудо-юдо решение длинною в жизнь.Проскипал статью через абзац, вроде есть зерно, но я ведь сам себе психолог хороший, посему пойду прокрастенировать и тревожиться дальше
Как вам такой вариант вашего примера с прибавляющимся счетчиком:
Работает без ИИ, только на чисто-функциональном эфире :)
А если попробовать таймауты у поиска сделать более щадящие, чтобы UI меньше зависал? Разделить сам поиск на маленькие чанки.
Какая разница в производительности между двумя потоками с асинхронным поиском и одним потоком, стоит ли игра свеч? Дублирование больших данных выглядит как сомнительный подход, не проще ли использовать IndexedDB для этого?
Все основные умеют. Разница между загрузкой html и парсинга в dom и загрузкой js и создания dom дерева минимальна. Все зависит от размера и сложности библиотеки которая этим занимается. Fusor маленький и быстрый, поэтому разница по скорости с ssr будет не заметна.
В основном согласен с вами. Единственное что бы хотелось добавить, что использование библиотек - это хорошо и правильно. Если только эти библиотеки решают одну конкретную задачу и решают ее хорошо ("Do one thing and do it well").
Во первых нет другой альтернативы. Во вторых это к банкам вопрос, могли бы сессию и дольше сделать. Наприме в Гугль входишь и годами сессия активна.
Оправдали и продолжают развиваться. Яблоко должно страдать за то что тормозят инновации в угоду наживы. Их уже Евросоюз дожимает на установку сторонних броузеров. И пользователям было бы морально их бойкотировать за это.
В хроме на анроиде нормальная установка, а на десктопе у меня около 40 приложений PWA. Я знаете ли не люблю проприетерное ПО которое может делать что-то плохое на моем компе. А вот в безопасном броузерном сэндбоксе - пожалуйста!
Всё когда-то было ново и неизведанно. И это не повод чтобы отказываться от прогресса. Если ваше приложение действительно нужно людям, то они в лепёшку разобьются чтобы его установить.
Российские банковские приложения - хороший пример.
Оба - фреймворки. Оба средней производительности, "good enough", заточены под все и ничего. SSR становится не актуальным, поисковики спокойно парсят CSR/SPA. Мобильная разработка становится не актуальной при развитии PWA. JSX это просто способ вызова функций, что гораздо лучше чем новый кастомный синтаксис для Javascript. Если нужен контроль, простота и производительность, то лучше так фронтэнд готовить.
Напомню, что джуном (в западных компаниях) считается человек с менее 6 годами опыта.
У этих ребят у самих "корона" которую не мешало бы сбить, для их же блага. Интервью не мешало бы записывать, и потом делать ревью хотябы одним-двумя людьми. А то может там самовлюбленный школьник сидит, натасканный на олимпиадных задачках, заворачивающий хороших кандидатов.
Нормальное формирование переходов это хорошая практика вэб-разработки. Вставить ссылки на переходы это совсем простая задача.
А вот в серверным код подмешивать клентский, также мы делали во времена вэб 1.0 на ПХП - это и усложнение серверного кода, и усложнение клиентского кода, и усложнение всего приложения в целом, и усложнение разработки и АПИ. Это и дополнительная нагрузка на сервер, это работает медленнее чем забрать оптимизированный клиент из CDN, это всё остально что еще не учел, что из этого вытекает...
Может эта проблема, которую мы сами себе создаем, а потом героически пытаемся решить? Неужели нельзя правильно ссылки сделать?
А вы уверены что у вас все переходы сделаны правильно через ссылки как описано выше? Также, что они присутствуют в DOM? Так как в при скрытии менюшки, это типичная практика, они оттуда удаляются. А Гугл не будет кликать по менюшке чтобы ее открыть.
По виду вы там использовали Material-UI. Это тяжелый и медленный монстр, в котором скорей всего вышеописанное сделано через одно место)
Но у вас всегда остается возможность сделать sitemap.
Видимо имелось в виду что не будет кликать по не семантическим навигационным элементам. Например если мы на
div
повесим событиеonclick
то Гугл не может знать, это переход или изменение темы CSS. Поэтому и привел что написано дальше, правильно формировать переходы по ссылкам<a href="...
, в том числе и для табов.Плюсом идет отдельная штука как sitemap, которая параллельно может решить эту проблему.
Вообще не вижу смысла спорить дальше, потому что доказано уже на практике, что SPA без SSR отлично индексируются.
В статье говорится об обратном.
Думаю нам пора уже пересмотреть устаревшие (с 2018 года) догматы.
Internal linking and URL structure: Create a clear, logical internal linking structure. Implement important navigational links as real HTML anchor tags (
<a href="...">
) rather than JavaScript-based navigation. This approach aids both user navigation and search engine crawling efficiency while potentially reducing rendering delays.Sitemaps: Use and regularly update sitemaps. For large sites or those with frequent updates, use the
<lastmod>
tag in XML sitemaps to guide Google's crawling and indexing processes. Remember to update the<lastmod>
only when a significant content update occurs.Вот не люблю я не свободное ПО. Поэтому устанавливаю его только как PWA, в безопасном броузерном сэндбоксе. Чего и вам советую.
Кстати обратите внимание на 2 версии VSCode (личная и рабочая) установленных тоже как вэб приложения. Это работает в докере и локальном браузере, избегая загрузки электрона.