Это, наверное, не совсем корректное сравнение. Хотя бы потому что команда телеграма занимается только телеграмом, а ватсап это один из продуктов фейсбука. Тут дело вовсе не в том кто эффективней, а как компания выделяет ресурсы на тот или иной продукт
Я тоже думал над подобной архитектурой, только через git submodules. По идеи разницы нет как собирать -- "монолитный" SPA из артефактов или делать MPA на основе модулей. В любом случае все повторяющиеся зависимости можно вынести в условные вендоры и тянуть как AMD/UMD тем самы м сохранив и масштабируемость и перформанс, но по сути это будет уже фреймворк, который реализует микросервисы на фронте
Думаю тут каждому свое. Пробовал пользоваться механикой, но так же не понял прикола, кроме длинного хода клавиш. Я вообще за мембранки с ножничным типом или бабочки как у яблока. У них ход клавиш короткий и текста набирать как будто приятней.
Хотя с другой стороны главное именно расположение(расстояние) и размер кнопок а не их тип.
Ну и да, если целенаправленно не ломать -- то клава живет и более 20 лет
Вроде как можно подменять номер. А если можно подменить -- значит можно сделать так чтобы звонить с фермы а у абонента "на том конце" светился всегда 1 номер. Но можно идти еще дальше и сделать децентрализованную ферму.
Но да, операторы сами могут определить аномальную активность как на какой-нибудь точке связи, так и в целом на номере. Сбер же лочит карту за крупные и/или частые переводы после длительного "простоя", условно.
Субъективно -- будет норм, когда будет устройство, которое позволит выполнять любые задачи без какой-либо периферии, при этом размером не более iPhone 4
Мне видится несколько причин -- самые очевидные: 1. Производительность таких устройств 2. Применимость -- тут в целом можно отталкиваться от первого пункта, например, какой-нибудь 3ds Max не запустишь потому что или не хватит памяти (любой) или мощности. 3. Эргономика -- клавомышь таки удобнее, а таскать их собой не самое комфортное занятие + еще нужен хаб, чтобы все подключить к доку 4. Цена таких устройств
Просто, например, в самолете или поезде я могу с ноутбука по кодить или посмотреть фильм. Со смартфоном я могу только посмотреть фильм, а если он умеет в Dex или Continuum то для решения более сложной задачи мне все равно потребуется экран, клавиатура и сам док
Ну блин, вы просто ищете ответы на риторические вопросы.
И я не говорю что это все "не решаемо", просто сейчас все эти адаптации решают одни и те же проблемы немного разными способами и на данный момент нет никакой панацеи.
А "база" и не должна успевать, имхо, без этого не будет развития.
Но с другой стороны я еще ни разу не видел чтобы "база" не могла решить проблемы бизнеса без каких то ухищрений. Опять же если касаться фреймворков с их модульностью и компонентами -- есть веб компоненты, теневой дом и umd, которые существуют давно, для реактивности -- mutation observer, например. И без всяких ухищрений можно писать на ванильке без оберток и не париться.
Предлагаю на этом остановиться. Я понимаю что вы имеете ввиду, но у меня просто свой взгляд на этот счет :)
Реакт не технология и даже не фреймворк. Почему он появился? Потому что захотели менее трудозатратную разработку фронта, с порогом входа на уровне jQuery
Jsx тоже не технология -- это шаблонизатор.
Так и что в итоге за кем не поспевает?)
То что мы сейчас делаем на фронте -- это просто наши больные фантазии, которые работают через костыли типа SPA и велосипеды типа фреймворков.
Почему все это происходит -- потому что мы живем с тем "наследием" которое имеем, да мы можем придумывать все новые велосипеды, но и они будут иметь под капотом все то же "наследие" (пример -- классы в es6). А просто так взять и создать какой-то новый подход мы тупо не можем т.к. переход на него будет идти вечность, как пример -- мы дружно не начали юзать wasm :)
Так вот проблема в том что это все только кажется. Фреймворки придумали чтобы сократить трудозатраты и только. Все остальное, включая сами фреймворки, реализуется за счет стандартных средств, которые со временем расширяются. Сейчас в ванильном js (браузерном) можно даже файлы с флешки читать, даже vr приложуху запилить.
Не в обиду будет сказано, но примерно года с 2018 (если не раньше) люди перестали учить js, кроме каких то основ, а учат только фреймворки.
Возможно по этому возникают такие ощущения, что якобы js -- костыль, а реакт -- крутая фича, и это печально. Да порог входа вырос, но обучаются люди не с того конца сейчас.
Если капнуть исходники реакта -- то мы увидим все те же методы для работы с DOM
Ну так они реализуют виртуальный DOM, т.е. по сути еще один уровень абстракции, реализованный в js для управления DOM.
Тут просто нужно понимать что веб зарождался совсем не для того, чтобы мы использовали так как используем сейчас. Изначально он был придуман как файлообменник для документов в формате html (упрощенный LaTeX(латех) в формате xml, если прям ну очень грубо) и то что в него приплели js тоже дело случая, например, на тот момент action script шагнул чутка дальше чем js. И вот мы живем просто с наследием которое вообще не должно было работать так как работает сейчас, и поэтому кажется что "все не продуманно".
И да, по моему имхо фреймворки тоже костыли) А вся разница в костылях заключается только в том что кому то нравиться одно, а кому то другое и тут нет никакой предвзятости
Не совсем и не всегда) Просто если говорить о js фреймворках то там уже есть редер функции которые, по сути, являются некой абстракцией над document.createElement и заводить еще один уровень поверх кажется, как минимум, странным)
А если судить о других технологиях -- то там XML строится для формирования модели интерфейса и где-то можно в явном виде на него воздействовать, а где то -- нет.
Если вот прям совсем не хочется с html контактировать -- можно воспользоваться canvas, но там придется реализовать свой DOM, который также может быть в JSON, XML или даже Yaml
Если выбирать вариант из предложенных -- никакой. При больших объемах работ просто нужно иметь достаточно большую коллекцию компонент/шаблонов/сниппетов чтобы быстро накидывать интерфейс.
Вообще, насколько я понял автору не очень нравится то что мы используем html для описания dom, поэтому вместо отлаженного синтаксического сахара которые предоставляют фреймворки (которые, кстати, частично упрощают жизнь) он начал придумывать свои велосипеды.
Так уж исторически сложилось что для отображение в вебе мы используем частный случай xml и управляем мы им из js, только потому что "ну вот так вышло". И мы придумали способы для упрощения формирования страниц. Это шаблонизаторы -- twig, pug, razor и т.д., которые позволяют выполнить так называемый code splitting, что уже ускоряет разработку.
В общем, мы ничем более не ускоримся если просто будем менять один синтаксический сахар на другой. А хранить верстку в переменных или выбирать компонент из списка через условия, просто ради красивой функции, то это бред
Сферический конь в вакууме такого рода обычно решается просто подтягиванием любого готового UI кита, который закрывает 70% работы) Но если сложно писать большие конструкции в том же jsx, то всегда есть Pug
Какой-то странный пост. Прочитав заголовок мне стало интересно какую аналогию проводят, например, .Net разработчики, сравнивая Razor с React (пример из воздуха). Ну или опыт подключения того же Angular в MVC, какие трудности преодолевали и т.д.
А тут просто набор фрейморков и описание из википедии (утрирую).
А зачем @svgr/webpack, если он все равно не используется?
С другой стороны зачем использовать @svgr/cli если есть webpack?
Еще в реализации есть косяк -- index файл сам не генерится, а это значит что нужно либо руками его описывать, либо делать костыль, который будет пробегаться по директории и все иконки собирать в модуль.
Вообще подход с cli имеет место быть если пак иконок уже готов и его нужно один раз добавить в проект.
Если же идет активная разработка -- нужно генерить иконки "на лету" вебпаком и тянуть их как обычные .svg, при этом в "реакте" они уже будут иметь jsx верстку, но в идеале к ним нужно генерить .d.ts чтобы корректно работал IntelliSence
Это, наверное, не совсем корректное сравнение. Хотя бы потому что команда телеграма занимается только телеграмом, а ватсап это один из продуктов фейсбука. Тут дело вовсе не в том кто эффективней, а как компания выделяет ресурсы на тот или иной продукт
Интересно чем у них занимаются аналитики, раз разработчик отвечает за бантики)
Все тоже самое на фронте.
Я тоже думал над подобной архитектурой, только через git submodules. По идеи разницы нет как собирать -- "монолитный" SPA из артефактов или делать MPA на основе модулей. В любом случае все повторяющиеся зависимости можно вынести в условные вендоры и тянуть как AMD/UMD тем самы м сохранив и масштабируемость и перформанс, но по сути это будет уже фреймворк, который реализует микросервисы на фронте
Думаю тут каждому свое. Пробовал пользоваться механикой, но так же не понял прикола, кроме длинного хода клавиш. Я вообще за мембранки с ножничным типом или бабочки как у яблока. У них ход клавиш короткий и текста набирать как будто приятней.
Хотя с другой стороны главное именно расположение(расстояние) и размер кнопок а не их тип.
Ну и да, если целенаправленно не ломать -- то клава живет и более 20 лет
Вроде как можно подменять номер. А если можно подменить -- значит можно сделать так чтобы звонить с фермы а у абонента "на том конце" светился всегда 1 номер. Но можно идти еще дальше и сделать децентрализованную ферму.
Но да, операторы сами могут определить аномальную активность как на какой-нибудь точке связи, так и в целом на номере. Сбер же лочит карту за крупные и/или частые переводы после длительного "простоя", условно.
Субъективно -- будет норм, когда будет устройство, которое позволит выполнять любые задачи без какой-либо периферии, при этом размером не более iPhone 4
Мне видится несколько причин -- самые очевидные:
1. Производительность таких устройств
2. Применимость -- тут в целом можно отталкиваться от первого пункта, например, какой-нибудь 3ds Max не запустишь потому что или не хватит памяти (любой) или мощности.
3. Эргономика -- клавомышь таки удобнее, а таскать их собой не самое комфортное занятие + еще нужен хаб, чтобы все подключить к доку
4. Цена таких устройств
Просто, например, в самолете или поезде я могу с ноутбука по кодить или посмотреть фильм. Со смартфоном я могу только посмотреть фильм, а если он умеет в Dex или Continuum то для решения более сложной задачи мне все равно потребуется экран, клавиатура и сам док
Просто в NDA нужно вписать пункты про LLM и таких сеньеров-помидоров рядить по статье)
Так DOM на то и DOM что это Document Object Model :)
Это один из результатов работы браузера. Если нужно работать со стилями -- есть CSSOM (CSS Object Model)
https://developer.mozilla.org/ru/docs/Web/API/CSS_Object_Model
Может быть стоит подтянуть основы, ибо вы хотите чтобы то что формирует структуру еще и формировало UI
https://habr.com/ru/companies/skillfactory/articles/678400/
Ход ваших мыслей, конечно, интересный, но "все придумано до нас"
Ну блин, вы просто ищете ответы на риторические вопросы.
И я не говорю что это все "не решаемо", просто сейчас все эти адаптации решают одни и те же проблемы немного разными способами и на данный момент нет никакой панацеи.
А "база" и не должна успевать, имхо, без этого не будет развития.
Но с другой стороны я еще ни разу не видел чтобы "база" не могла решить проблемы бизнеса без каких то ухищрений. Опять же если касаться фреймворков с их модульностью и компонентами -- есть веб компоненты, теневой дом и umd, которые существуют давно, для реактивности -- mutation observer, например. И без всяких ухищрений можно писать на ванильке без оберток и не париться.
Предлагаю на этом остановиться. Я понимаю что вы имеете ввиду, но у меня просто свой взгляд на этот счет :)
Очень холиварно получилось, но продолжим)
Какие технологии?)
Реакт не технология и даже не фреймворк. Почему он появился? Потому что захотели менее трудозатратную разработку фронта, с порогом входа на уровне jQuery
Jsx тоже не технология -- это шаблонизатор.
Так и что в итоге за кем не поспевает?)
То что мы сейчас делаем на фронте -- это просто наши больные фантазии, которые работают через костыли типа SPA и велосипеды типа фреймворков.
Почему все это происходит -- потому что мы живем с тем "наследием" которое имеем, да мы можем придумывать все новые велосипеды, но и они будут иметь под капотом все то же "наследие" (пример -- классы в es6). А просто так взять и создать какой-то новый подход мы тупо не можем т.к. переход на него будет идти вечность, как пример -- мы дружно не начали юзать wasm :)
Так вот проблема в том что это все только кажется. Фреймворки придумали чтобы сократить трудозатраты и только. Все остальное, включая сами фреймворки, реализуется за счет стандартных средств, которые со временем расширяются. Сейчас в ванильном js (браузерном) можно даже файлы с флешки читать, даже vr приложуху запилить.
Не в обиду будет сказано, но примерно года с 2018 (если не раньше) люди перестали учить js, кроме каких то основ, а учат только фреймворки.
Возможно по этому возникают такие ощущения, что якобы js -- костыль, а реакт -- крутая фича, и это печально. Да порог входа вырос, но обучаются люди не с того конца сейчас.
Если капнуть исходники реакта -- то мы увидим все те же методы для работы с DOM
Ну и так, просто посмотри сколько всего есть в js в "стоке" -- https://developer.mozilla.org/ru/docs/Web/API
Ну так они реализуют виртуальный DOM, т.е. по сути еще один уровень абстракции, реализованный в js для управления DOM.
Тут просто нужно понимать что веб зарождался совсем не для того, чтобы мы использовали так как используем сейчас. Изначально он был придуман как файлообменник для документов в формате html (упрощенный LaTeX(латех) в формате xml, если прям ну очень грубо) и то что в него приплели js тоже дело случая, например, на тот момент action script шагнул чутка дальше чем js. И вот мы живем просто с наследием которое вообще не должно было работать так как работает сейчас, и поэтому кажется что "все не продуманно".
И да, по моему имхо фреймворки тоже костыли) А вся разница в костылях заключается только в том что кому то нравиться одно, а кому то другое и тут нет никакой предвзятости
Не совсем и не всегда) Просто если говорить о js фреймворках то там уже есть редер функции которые, по сути, являются некой абстракцией над
document.createElementи заводить еще один уровень поверх кажется, как минимум, странным)А если судить о других технологиях -- то там XML строится для формирования модели интерфейса и где-то можно в явном виде на него воздействовать, а где то -- нет.
Если вот прям совсем не хочется с html контактировать -- можно воспользоваться canvas, но там придется реализовать свой DOM, который также может быть в JSON, XML или даже Yaml
Если выбирать вариант из предложенных -- никакой. При больших объемах работ просто нужно иметь достаточно большую коллекцию компонент/шаблонов/сниппетов чтобы быстро накидывать интерфейс.
Вообще, насколько я понял автору не очень нравится то что мы используем html для описания dom, поэтому вместо отлаженного синтаксического сахара которые предоставляют фреймворки (которые, кстати, частично упрощают жизнь) он начал придумывать свои велосипеды.
Так уж исторически сложилось что для отображение в вебе мы используем частный случай xml и управляем мы им из js, только потому что "ну вот так вышло". И мы придумали способы для упрощения формирования страниц. Это шаблонизаторы -- twig, pug, razor и т.д., которые позволяют выполнить так называемый code splitting, что уже ускоряет разработку.
В общем, мы ничем более не ускоримся если просто будем менять один синтаксический сахар на другой. А хранить верстку в переменных или выбирать компонент из списка через условия, просто ради красивой функции, то это бред
Сферический конь в вакууме такого рода обычно решается просто подтягиванием любого готового UI кита, который закрывает 70% работы) Но если сложно писать большие конструкции в том же jsx, то всегда есть Pug
А еще Black Arch :)
Какой-то странный пост. Прочитав заголовок мне стало интересно какую аналогию проводят, например, .Net разработчики, сравнивая Razor с React (пример из воздуха). Ну или опыт подключения того же Angular в MVC, какие трудности преодолевали и т.д.
А тут просто набор фрейморков и описание из википедии (утрирую).
А зачем
@svgr/webpack, если он все равно не используется?С другой стороны зачем использовать
@svgr/cliесли есть webpack?Еще в реализации есть косяк -- index файл сам не генерится, а это значит что нужно либо руками его описывать, либо делать костыль, который будет пробегаться по директории и все иконки собирать в модуль.
Вообще подход с cli имеет место быть если пак иконок уже готов и его нужно один раз добавить в проект.
Если же идет активная разработка -- нужно генерить иконки "на лету" вебпаком и тянуть их как обычные .svg, при этом в "реакте" они уже будут иметь jsx верстку, но в идеале к ним нужно генерить .d.ts чтобы корректно работал IntelliSence
А чем C3D лучше, например, Fusion 360 или других более доступных кадов?