напишите в начале
- Недавно я написал две статьи, одна из них:
petite-vueАнализ исходного кода и анализ исходного кода редактора Nuggets и выявление того, что он в нем используетсяSvelteэтот кадр - В дополнение к недавнему React17 все постепенно используют vite в производственной среде, поэтому у меня сегодняшнее мышление
Посмотрите на технологическую эволюцию интерфейса
- Родной
Javascript - JqueryДля эпохи, представленной, например, введениемJqueryесли только
<script src="cdn/jquery.min,js"></script>
- Тогда есть еще один
gulpwebpackКогда появились инструменты сборки, React и Vue также начали загораться в это время, за ними последовало множество инженерных вспомогательных инструментов, таких какbabel, а также полный комплекс услугcreate-react-appв ожидании строительных лесов - Это также приносит проблемы, конечно, это
npmКаждый раз при запуске проекта приходится устанавливать большое количество зависимостей.Даже при наличии оптимизированных инструментов управления зависимостями, таких как yarn pnpm`, первопричина этой проблемы должна решаться не инструментами, а сутью проблемы полагаться на локализацию, код и зависимости требуют помощи инструмента для запуска в браузере
Резюме: существующий режим разработки делает проект слишком тяжелым, например, я хочу использовать определенные леса, я просто хочу написать
helloworldДемо, получилось позволить мне установить500mbЗависимость, разные строительные леса, разные конфигурации, разные продукты
идеальная модель развития
-
1. Не требуется настройка дополнительных инструментов, мне не нужны такие инструменты, как webpack, чтобы помочь мне упаковать, сам модульный браузер поддерживает это, и это спецификация. Например
viteГоворят, что он не запакован, его поддерживает сам браузерesmМодульный, но он не решает проблему зависимостей, потому что проблема зависимостей — это проблема зависимостей, а не проблема инструментов -
2. Не нужно устанавливать зависимости, все работает
import from remote,Я думаюwebpack5изModule FederationВ дизайне это учтено, и ниже приводится официальное объяснение:-
Несколько независимых сборок могут составлять приложение, и между этими независимыми сборками не должно быть никаких зависимостей, поэтому их можно разрабатывать и развертывать по отдельности.
-
Это часто называют микро-интерфейсом, но это не ограничивается этим.
-
Но это может быть не лучшая практика, в настоящее время
import from http,Например
import lodash from 'https://unpackage/lodash/es'
- Тут еще кто-то спросит, неужели вы все не хотите слать запросы, всем приходится дергать удаленно каждый раз при запуске, лучше делать это локально.
import from httpЯ думаю, это просто решает точечную проблему, то есть нет необходимости вручную устанавливать зависимости на локальный диск - Некоторое время назад я писал о локальном запуске Node.js в браузере.
Эта технология называется
WebContainersТехнология, если интересно, можете пройтись по предыдущим статьям моего официального аккаунта
- Подожди, не волнуйся. Это только начало. Новые технологии часто нужно исследовать, чтобы максимизировать ценность. Я думаю, что это должно полностью разрушить существующую модель развития, и это должно быть в течение 3-5 лет.
Интегрировать несколько новых концепций передовых технологий?
-
viteНе упаковывайте концепцию: прямое использование поддержки браузераesmмодульный -
WebContainersТехнология: пусть браузер работает напрямуюnode.js -
import from remote, Напрямую импортировать зависимости, которые можно использовать с удаленных адресов - Сейчас жарко
webIDE:аналогичныйremixРедактор, все можно сделать прямо в облаке - Оптимизация браузера с естественной поддержкой кеша
Что изменится?
- Все наше начало, просто запустите браузер
- в браузере
webIDE, вы можете напрямую вводить удаленные зависимости, и браузер может работатьNode.js, используя обаesmМодульный, инструменты для упаковки не требуются, время запуска проекта и время горячего обновления очень короткое, а сборка также может быть собрана прямо в браузере.
Кажется, они решают большинство проблем, которые мы поднимали ранее, вернемся к сегодняшней теме.
вернуться к теме
- Вернется ли передняя часть к исходной работе?
domэпоха? - Я думаю, есть такая тенденция, как
petite-vue,а такжеSvelte.
потому что это было написано раньше
petite-vueИсходный код разобран, об этом мы сегодня и поговоримSvelte
Svelte
Svelteэто совершенно новый способ создания пользовательских интерфейсов. В то время как традиционные фреймворки, такие как React и Vue, требуют много работы в браузере, Svelte переносит эту работу на этап компиляции создания приложения.
- В отличие от использования виртуального (виртуального) DOM diff. Svelte пишет код, который обновляет DOM, как операцию, при изменении состояния приложения.
-
Вышеизложенное является официальным введением, давайте взглянем на эту статью Чжиху
https://zhuanlan.zhihu.com/p/97825481, я чувствую, что он написал очень хорошо, скопируйте прямо сюда -
React и Vue — это среды выполнения. Так называемый фреймворк, основанный на времени выполнения, означает, что код самого фреймворка также будет упакован в финальный bundle.js и отправлен в браузер пользователя.
-
Когда пользователь выполняет различные операции на вашей странице для изменения состояния компонента, среда выполнения фреймворка будет вычислять (diff), какие узлы DOM необходимо обновить в соответствии с новым состоянием компонента (состоянием).
Однако эти упакованные фреймворки слишком велики.
(Я до сих пор говорю своим коллегам, что сайт авторизации, который я написал за год до этого, был полностью создан вручную и обладал непобедимой производительностью)
-
100kbДля слабого сетевого окружения это ужасно, посмотримsvelteНа сколько уменьшился объем:
научно-популярный
- виртуальный
domЭто не увеличивает скорость отклика браузера пользователя, просто его проще использовать для представлений, управляемых данными, проще в управлении и в определенной степени медленнее. Реальный самый быстрый всегда:
currentDom.innerHtml = '前端巅峰';
так
SvelteДело не в том, насколько он хорош, а в его концепции, которая может стать все более и более популярной в будущем.
Изменения в React17
- Всем должно быть известно, что существующие браузеры не могут напрямую интерпретировать JSX, поэтому большинству пользователей React необходимо использовать компилятор, такой как Babel или TypeScript, для преобразования JSX в язык JavaScript, понятный браузерам. Многие предварительно настроенные наборы инструментов (такие как Create React App или Next.js) также содержат преобразования JSX.
- React 17.0, хотя команда React хотела внести улучшения в преобразование JSX, команда React не хотела нарушать существующую конфигурацию. Вот почему команда React объединилась с Babel, чтобы предоставить новую версию преобразований JSX для разработчиков, которые хотят выполнить обновление.
- С совершенно новой трансформацией вы можете использовать только JSX, не прибегая к React.
Я предполагаю, что, возможно, команда React намеренно продвигает синтаксис jsx, чтобы он стал стандартным синтаксисом es, и есть надежда, что он будет значительно улучшен, если его убрать.
фокус
- Сказав так много, вы, возможно, не поняли главного, а именно: каждый думает о том, чтобы уменьшить собственную нагрузку, стандартизировать то, что они оставили, и передать это браузеру для обработки.Это также на будущее, кто нужно только открыть браузер. , вы можете сделать все, чтобы проложить путь
- И я считаю, что этот день не за горами, насколько я знаю, уже есть много топовых команд, разрабатывающих этот вид продукта.
напиши в конце
- Если у вас есть какие-либо вопросы, напишите мне сообщение ниже
- Если вы чувствуете, что пишете хорошо, помогите моему паблику:
前端巅峰нажмите在看/赞/关注Три в ряд, оригинальность не из легких