косвенно но туда же "Ложная слепота"
про язык там меньше чем про сознание и самосознание, но отдельные аспекты того как местные инопланетяне используют человеческие языки (вроде бы несколько) очень любопытна.
совершенно забыл про transition хуки. Да, небольшой дескреп все же есть (ErrorBoundary только классы, а некоторые фичи suspense — только хуками) но как правило эти элементы абстрагированы в библиотеки.
По большому счету можно продолжать использовать классы.
за вычетом двух проблем — порядок хуков и их количество должно соблюдаться и передача объектов в массив зависимостей — все остальное — это by design и в общем-то плюс.
Первая проблема нерешаема вообще но вобщем-то терпима и ничего страшного за собой не несет;
Вторая проблема решается (или подталкивает к решению) через оптимизацию зависимостей и понимание того откуда приходят эти зависимости, и решиться окончательно когда завезут поддержку tuple и record — массивы и объекты которые сравниваются по значению а не по референсу;
При этом хуки несут:
1) инкапсуляцию логики; теперь любую сложную логику можно хранить в одном месте и видеть порядок выполнения;
2) более простую типизацию, хуки принимают и отдают (как правило) легко типизируемые структуры данных;
3) более простую логическую модель. Не нужно знать о конкретных компонентах и их lifecycle, достаточно знать на самом деле что есть хуки для хранения состояния (useState, и useRef) и для вызова эффектов (useEffect/useLayoutEffect). Все остальное — композиция этих двух типов хуков;
4) легковесность. Хуки прекрасно выносятся в пакеты и живут потом в react/react-native проектах;
5) оптимизация и дебаг. Если у вас тысяча и один рендер вызываются на каждый чих то гораздо проще локализовать источник проблемы и оптимизировать хук чем продираться через древо компонентов.
Являются ли хуки серебряной пулей? нет конечно, ни один из инструментов/паттернов не является. Да, асинхронные операции чуть более боль чем хотелось бы и массив зависимостей может выстрелить в ногу при невнимательности.
К тому же хуки абсолютно опционально, и если бы комьюнити (ну или у вас в конкретном проекте) решили что классы это то что вам нужно — никто не запрещает продолжать пользоваться ими.
Expo — отличный инструмент, позволяет быстро запустить приложение. При условии что ваше приложение не завязано на кастомные нативные модули — обычные списки, тест, картинки, графики вот это все.
Но даже если вы думаете что ваше приложение не завязано на свои нативные модули, рано или поздно встанет вопрос съезда с expo. К вам придет отдел маркетинга и попросит интегрировать аналитику которая не поддерживается expo. Вы обнаружите баг который нельзя пропатчить в expo и можно только ждать следующего sdk. Вы гарантировано будете отставать на несколько версий reanimated, gesture-handler, react-native.
В сумме, если у вас есть время и ресурсы и вы пишите приложение а не proof-of-concept — начинайте сразу с react-native. это чуть сложнее, но в конечном итоге стоит того.
Кроме того большая часть библиотек expo ставятся через unimodules — кроме разве что пушей и over-the-air-updates. Первая решается нативным пушами, вторая — AppCenter code-push.
Помочь в конкретном случае может и бабка-шептунья;
Но назначать лечение, выписывать рецепты может только врач. К ним предъявляются требования в плане образования, требования к практике, а так же они несут юридическую ответственность за неправильное лечение.
Тут очень тонкий момент. Я могу назвать себя психологом и повесить рамку на стену. И все, я — психолог. А врачем — не могу, у меня нет соответствующего образования и если я себя назову психиатром — это уголовная статья:
Право на осуществление медицинской деятельности в Российской Федерации имеют лица, получившие медицинское или иное образование в Российской Федерации в соответствии с федеральными государственными образовательными стандартами и имеющие свидетельство об аккредитации специалиста.
Лица, незаконно занимающиеся медицинской деятельностью и фармацевтической деятельностью, несут уголовную ответственность в соответствии с законодательством Российской Федерации.
Психолог — не лечит. Психолог — не врач. Врач — психиатр или невролог;
Врач-психиатр почти всегда назначает анализы и консультацию невролога.
Пожалуйста не путайте, это очень важно. Грань тонкая, но критически важная.
Что не отменяет наличие психологов с образованием врача. но это нужно проверять.
И так же не значит что психолог это "плохо", а психиатр — "хорошо". У каждого свои задачи.
Советуют при дефиците именно инъекции, ибо B12 в пище усваивается плоховато и быстро дефицит не восполнить.
Врачи регулярно прописывают именно инъекции (огромная доля посетителей психоневрологических диспансеров там за уколом B1-B6-B12 — их дефицит связан с депрессией, зачастую витаминов достаточно для лечения)
Простите, но накипело.
Задолбали ныть.
Ну серьезно, не в первый раз приходят и начинают осуждать естественный процесс эволюции веба, который десятилетиями шел своим путем с участием тысяч (миллионов?) людей, компаний, которые решали задачи, развивали бизнес и прочее.
Никто ничего не усложнил. Ну не нравится babel, react, webpack — открывайте <script> и пишите. Обратная совместимость со старьем поддерживается если не абсолютно, то близко к тому.
Тоже много читал про проблемы с покупкой техники apple в США но сам заказывал айпады (не айфоны — возможно это важно) и не на старте продаж (возможно тоже важно) дважды — и просто указывал адрес почтовой ячейки бандерольки (они же qwintry) как есть, просто оплачивал своей российской дебетовой master card (списывали в $), на свой стандартный российский apple id и никто даже дополнительного вопроса не задал.
Более того, я общался по какому-то вопросу (кажется насчет поддержки европейский сетей lte) с американским суппортом и им тоже явно сообщал что покупаю себе в Россию и пользовать буду там — им было вообще пофиг.
в защиту провайдера — выбора у него не особо: не блокируешь — попадаешь на штрафы, статьи, закрываешься, финита.
Выбор у человека — работать/выполнять «преступный приказ» или нет. Ну и соответсвенно увольняться или нет.
Проблема решается не тут и не так.
Парадокс — если бы все люди были бы совестливые и героические то и законы были бы соответсвующие и героизм и совесть не понадобились :)
Это несправедливо. Конечно в идеальном мире можно было бы ожидать каких-то идеальных решений, созданных на идеальном API. Но в реальном мире приходится чем-то жертвовать.
Если под фронтендом имеется ввиду полторы анимации выпадающего меню на статичной странице-лэндинге тогда да, вполне возможно.
Идеальный ванильный фронтенд с обходом всех косяков всех браузеров (точно всех? и тесты есть?) и имеющий хоть сколько-нибудь интересный функционал — ну вот например банальный date-picker — но не тот про который вы скажете "ну используйте нативный type="date", а посложнее чуть — с подсветкой доступных для вылета дат (реальный кейс, помните у всех были сайты авиабилетов в 2011-2012 году?) или выбором внутри диапазона дат (тоже реальный кейс, уже из отельного бизнеса) будет писаться долго, муторно, а после ухода программиста его написавшего — еще и крайней неохотно поддерживаться.
Как только появляется необходимость управлять состоянием, синхронизацией с сервером, более-менее сложных асинхронных вариаций форм — все, привет. На ванильном коде далеко не уедешь (ну или уедешь но добираться будешь крайней долго)
окей. давайте так. у среднего реального проекта на react соотношение бандлов с вендоским кодом (все что в node_modules) и банда кода из src составляет 181кб/99кб. Только 60% кода реально попадающего клиенту (ну мы же не будем сравнивать размер папок с исходным кодом, право) — это код из node_modules (+ к этому tree shaking у вебпака работает так себе, я думаю можно снизить еще — было бы желание)
За эти 60% процентов вы «покупаете» себе предсказуемость, документацию, фиксы безопасности и баг-фиксы, поддержку комьюнити, расширяемость.
Так же по мере роста проекта в него все реже добавляются новые пакеты и все больше пишется своего кода, соотвественно использовать фреймворки будет все выгоднее и выгоднее.
Вот и вся метрика. с определенной степени сложности/размера приложения/частоты обновления становится выгодно использовать фреймворки, до определенного — это неоправданно дорого.
шёл 2018 год — дешевый черный пластик, micro-usb / usb 2.0, отсутсвие подсветки и утопленый дисплей с толстючими рамками (пробовали на таком рисовать пером? попробуйте, ощущения так себе) за $1к+ — через пару тройку лет дойдет до массового прозиводства в нормальном виде :)
Учитывая состояние данного рынка (дикий запад) — очень ожидаемая цифра.
Пока индустрия не устаканится не начнет регулироваться (или саморегулироваться) данную картину можно ожидать и дальше...
ох, тут по порядку:
1) бандла 2 — vendor.js и app.js; vendor.js включает в себя почти все из node_modules, app — соответственно код самого приложения. совокупно получается около 210-220кб в сжатом виде. Плюс такого подхода — пока мы не добавили зависимость или не обновили версию зависимости в package.json — vendor.js не инвалидируется. Ну и грузится параллельно;
2) нужно вручную следить что бы библиотки не утащили несколько версий lodash например или react-router+react-router/es или еще что-то типа того;
3) нужно следить за размером некоторых библиотек и выносить их вот так (или любым имным способом) в ленивую загрузку или уменьшать их размер если это возможно. популярный выстрел себе в ногу — momen.js и его локали: ;
4) uglify/gzip — разумеется; babili и иные минификаторы работают менее стабильно и дают эффект хоть и лучший — но не настолько лучший на моей практике что бы заморачиваться. пока опыт с ними отрицательный.
ну вот именно потому что параллельно — в результате получится быстрее (https://github.com/webpack/webpack/issues/3216 — тут подробнее).
Но это именно оптимизация — preload/prefetch имеет более низкий приоритет чем собственно скрипты, и вставлять вы можете его предполагая с какой вероятностью пользователю понадобится firebase на данной странице.
косвенно но туда же "Ложная слепота"
про язык там меньше чем про сознание и самосознание, но отдельные аспекты того как местные инопланетяне используют человеческие языки (вроде бы несколько) очень любопытна.
совершенно забыл про transition хуки. Да, небольшой дескреп все же есть (ErrorBoundary только классы, а некоторые фичи suspense — только хуками) но как правило эти элементы абстрагированы в библиотеки.
По большому счету можно продолжать использовать классы.
за вычетом двух проблем — порядок хуков и их количество должно соблюдаться и передача объектов в массив зависимостей — все остальное — это by design и в общем-то плюс.
Первая проблема нерешаема вообще но вобщем-то терпима и ничего страшного за собой не несет;
Вторая проблема решается (или подталкивает к решению) через оптимизацию зависимостей и понимание того откуда приходят эти зависимости, и решиться окончательно когда завезут поддержку tuple и record — массивы и объекты которые сравниваются по значению а не по референсу;
При этом хуки несут:
1) инкапсуляцию логики; теперь любую сложную логику можно хранить в одном месте и видеть порядок выполнения;
2) более простую типизацию, хуки принимают и отдают (как правило) легко типизируемые структуры данных;
3) более простую логическую модель. Не нужно знать о конкретных компонентах и их lifecycle, достаточно знать на самом деле что есть хуки для хранения состояния (useState, и useRef) и для вызова эффектов (useEffect/useLayoutEffect). Все остальное — композиция этих двух типов хуков;
4) легковесность. Хуки прекрасно выносятся в пакеты и живут потом в react/react-native проектах;
5) оптимизация и дебаг. Если у вас тысяча и один рендер вызываются на каждый чих то гораздо проще локализовать источник проблемы и оптимизировать хук чем продираться через древо компонентов.
Являются ли хуки серебряной пулей? нет конечно, ни один из инструментов/паттернов не является. Да, асинхронные операции чуть более боль чем хотелось бы и массив зависимостей может выстрелить в ногу при невнимательности.
К тому же хуки абсолютно опционально, и если бы комьюнити (ну или у вас в конкретном проекте) решили что классы это то что вам нужно — никто не запрещает продолжать пользоваться ими.
Expo — отличный инструмент, позволяет быстро запустить приложение. При условии что ваше приложение не завязано на кастомные нативные модули — обычные списки, тест, картинки, графики вот это все.
Но даже если вы думаете что ваше приложение не завязано на свои нативные модули, рано или поздно встанет вопрос съезда с expo. К вам придет отдел маркетинга и попросит интегрировать аналитику которая не поддерживается expo. Вы обнаружите баг который нельзя пропатчить в expo и можно только ждать следующего sdk. Вы гарантировано будете отставать на несколько версий reanimated, gesture-handler, react-native.
В сумме, если у вас есть время и ресурсы и вы пишите приложение а не proof-of-concept — начинайте сразу с react-native. это чуть сложнее, но в конечном итоге стоит того.
Кроме того большая часть библиотек expo ставятся через unimodules — кроме разве что пушей и over-the-air-updates. Первая решается нативным пушами, вторая — AppCenter code-push.
Помочь в конкретном случае может и бабка-шептунья;
Но назначать лечение, выписывать рецепты может только врач. К ним предъявляются требования в плане образования, требования к практике, а так же они несут юридическую ответственность за неправильное лечение.
Тут очень тонкий момент. Я могу назвать себя психологом и повесить рамку на стену. И все, я — психолог. А врачем — не могу, у меня нет соответствующего образования и если я себя назову психиатром — это уголовная статья:
Психолог — не лечит. Психолог — не врач. Врач — психиатр или невролог;
Врач-психиатр почти всегда назначает анализы и консультацию невролога.
Пожалуйста не путайте, это очень важно. Грань тонкая, но критически важная.
Что не отменяет наличие психологов с образованием врача. но это нужно проверять.
И так же не значит что психолог это "плохо", а психиатр — "хорошо". У каждого свои задачи.
ну так чего вы тут с нами, идиотами да снобами, в песочнице сидите?
Советуют при дефиците именно инъекции, ибо B12 в пище усваивается плоховато и быстро дефицит не восполнить.
Врачи регулярно прописывают именно инъекции (огромная доля посетителей психоневрологических диспансеров там за уколом B1-B6-B12 — их дефицит связан с депрессией, зачастую витаминов достаточно для лечения)
Простите, но накипело.
Задолбали ныть.
Ну серьезно, не в первый раз приходят и начинают осуждать естественный процесс эволюции веба, который десятилетиями шел своим путем с участием тысяч (миллионов?) людей, компаний, которые решали задачи, развивали бизнес и прочее.
Никто ничего не усложнил. Ну не нравится babel, react, webpack — открывайте
<script>и пишите. Обратная совместимость со старьем поддерживается если не абсолютно, то близко к тому.Более того, я общался по какому-то вопросу (кажется насчет поддержки европейский сетей lte) с американским суппортом и им тоже явно сообщал что покупаю себе в Россию и пользовать буду там — им было вообще пофиг.
Выбор у человека — работать/выполнять «преступный приказ» или нет. Ну и соответсвенно увольняться или нет.
Проблема решается не тут и не так.
Парадокс — если бы все люди были бы совестливые и героические то и законы были бы соответсвующие и героизм и совесть не понадобились :)
NASA: 'Mission complete' for Mars Opportunity rover
Это несправедливо. Конечно в идеальном мире можно было бы ожидать каких-то идеальных решений, созданных на идеальном API. Но в реальном мире приходится чем-то жертвовать.
Если под фронтендом имеется ввиду полторы анимации выпадающего меню на статичной странице-лэндинге тогда да, вполне возможно.
Идеальный ванильный фронтенд с обходом всех косяков всех браузеров (точно всех? и тесты есть?) и имеющий хоть сколько-нибудь интересный функционал — ну вот например банальный date-picker — но не тот про который вы скажете "ну используйте нативный
type="date", а посложнее чуть — с подсветкой доступных для вылета дат (реальный кейс, помните у всех были сайты авиабилетов в 2011-2012 году?) или выбором внутри диапазона дат (тоже реальный кейс, уже из отельного бизнеса) будет писаться долго, муторно, а после ухода программиста его написавшего — еще и крайней неохотно поддерживаться.Как только появляется необходимость управлять состоянием, синхронизацией с сервером, более-менее сложных асинхронных вариаций форм — все, привет. На ванильном коде далеко не уедешь (ну или уедешь но добираться будешь крайней долго)
За эти 60% процентов вы «покупаете» себе предсказуемость, документацию, фиксы безопасности и баг-фиксы, поддержку комьюнити, расширяемость.
Так же по мере роста проекта в него все реже добавляются новые пакеты и все больше пишется своего кода, соотвественно использовать фреймворки будет все выгоднее и выгоднее.
Вот и вся метрика. с определенной степени сложности/размера приложения/частоты обновления становится выгодно использовать фреймворки, до определенного — это неоправданно дорого.
шёл 2018 год — дешевый черный пластик, micro-usb / usb 2.0, отсутсвие подсветки и утопленый дисплей с толстючими рамками (пробовали на таком рисовать пером? попробуйте, ощущения так себе) за $1к+ — через пару тройку лет дойдет до массового прозиводства в нормальном виде :)
Учитывая состояние данного рынка (дикий запад) — очень ожидаемая цифра.
Пока индустрия не устаканится не начнет регулироваться (или саморегулироваться) данную картину можно ожидать и дальше...
1) бандла 2 — vendor.js и app.js; vendor.js включает в себя почти все из node_modules, app — соответственно код самого приложения. совокупно получается около 210-220кб в сжатом виде. Плюс такого подхода — пока мы не добавили зависимость или не обновили версию зависимости в package.json — vendor.js не инвалидируется. Ну и грузится параллельно;
2) нужно вручную следить что бы библиотки не утащили несколько версий lodash например или react-router+react-router/es или еще что-то типа того;
3) нужно следить за размером некоторых библиотек и выносить их вот так (или любым имным способом) в ленивую загрузку или уменьшать их размер если это возможно. популярный выстрел себе в ногу — momen.js и его локали:
4) uglify/gzip — разумеется; babili и иные минификаторы работают менее стабильно и дают эффект хоть и лучший — но не настолько лучший на моей практике что бы заморачиваться. пока опыт с ними отрицательный.
либа не говно, просто большая. rest есть но не realtime и менее удобный.
ну вот именно потому что параллельно — в результате получится быстрее (https://github.com/webpack/webpack/issues/3216 — тут подробнее).
Но это именно оптимизация — preload/prefetch имеет более низкий приоритет чем собственно скрипты, и вставлять вы можете его предполагая с какой вероятностью пользователю понадобится firebase на данной странице.