Нет фреймворк что это: Для чего нужен Microsoft .NET Framework?

Из http://reactjs.org, пример #1

Довольно близко! Но как насчет компонентов с состоянием? В своих проектах я использую исключительно компоненты без состояния в сочетании с архитектурой с одним деревом состояний. Следовательно, я бы не рекомендовал использовать компонент с состоянием, но если вам это абсолютно необходимо, вот соответствующая реализация React Timer (опять же, довольно близкая):

Stateful ES6 Template Literal Component

Шаблонные литералы составляются хорошо, конечно, вот соответствующий образец Todo React (как компонент с отслеживанием состояния):

Template Literal Composition (ES6)

Сначала меня привлек JSX, но очень быстро вы понимаете что использование нотации Tag для указания вызова функции не добавляет большого значения, на самом деле это довольно негибко. Когда вы добавите к этому особенности JSX (вплоть до верблюжьего случая), кривую обучения и его ограничения по сравнению с полным доступом к HEC, осталось не так много причин для его использования.

Последний вопрос, как вы визуализируете эти компоненты? Менее 20 строк Javascript дадут вам реагирующий API

. 20-строчная реагирующая библиотека. Javascript (код доступен на CodePen.io во встроенном окне ниже):

React представил концепцию виртуального дома, которая в сочетании с функциональным HTML устранила необходимость прямых манипуляций с DOM. Опять же, вопрос, действительно ли вам это нужно? Я так не думаю: обычно я делю свои проекты на три части (шапка, контент и нижний колонтитул), которые отображаются независимо. Если вы чувствуете необходимость независимо отображать некоторые подразделы контента, я написал эти 20 строк Javascript, которые «хешируют» разные разделы и отображают только те, которые изменились.

ОБНОВЛЕНИЕ . После того, как я написал этот пост, Google (Джастин Фагнани) выпустил lit-html, библиотеку, которая делает этот подход еще более убедительным:

lit-html позволяет писать HTML шаблоны с литералами шаблонов JavaScript, а также эффективно отображать и повторно отображать этих шаблонов в DOM.

Управление состоянием сложно, и только React делает его намного сложнее. Вот почему такие библиотеки, как Redux, MobX… использовались для «поддержки» React. Проблема в том, что эти библиотеки тесно связаны с моделью программирования React, которая сама по себе не очень хорошо справляется с мутациями. Их единственная цель — скрыть мутации до тех пор, пока вы не дойдете до того момента, когда вы сможете разрешить рендеринг React. Но опять же, зачем вам создавать больше зависимостей? особенно если учесть, что модель программирования Redux и MobX далека от оптимальной. Вам не нужно! Вы можете использовать простой интуитивный шаблон: шаблон SAM. Шаблон SAM основан на самой надежной теории компьютерных наук на сегодняшний день, TLA+, и включает в себя мутацию, а не полагается на еще одну пожирательницу производительности — неизменность. Лучше всего то, что модель программирования SAM предназначена для интеграции вызовов API без каких-либо дополнительных библиотек, таких как Thunks, Saga, или большого количества осложнений при вызове API из компонентов React с отслеживанием состояния.

Архитектура приложения с шаблоном SAM

В качестве шаблона SAM очень легко реализовать, и я создал несколько начальных проектов, таких как этот. Я также создал небольшую библиотеку на случай, если вы ищете что-то готовое, и создал несколько примеров приложений TODOMVC , чтобы показать это в действии: (vanillajs, lit-html, react, vue).

Когда я написал свой первоначальный пост «Почему я больше не использую фреймворки MVC?» два года назад многие люди жаловались, что этот подход небезопасен. Во-первых, у меня есть новости для вас: React (или Angular) не защищает от CSRF, поскольку в нем есть серверный компонент. Проблема в том, что для создания безопасного веб-приложения вам нужно обрабатывать и XSS, и CSRF, одно без другого не работает. Их относительно легко реализовать с помощью HEC , снова буквально с несколькими строками Javascript. Для защиты веб-приложения нужно сделать гораздо больше, но, пожалуйста, не думайте, что фреймворк защитит вас.

“ Наш рабочий процесс по умолчанию усложнен потребностями больших веб-приложений. Эти приложения важны, но они не представляют всего, что мы делаем в Интернете, и, поскольку мы усложняем эти рабочие процессы, мы также усложняем обучение и адаптацию новых веб-разработчиков». — Mikeal

Я не хочу делать этот пост слишком длинным, но если я смогу убедить вас попробовать HTML5/ES6/CSS3/SAM Pattern, вы быстро увидите, что у них много преимуществ по сравнению с использованием фреймворка, и я уверен, что вы были бы рады почувствовать, насколько освежает этот подход (и я даже не говорю о веб-компонентах).

Front-End Frameworks просто раздуты, насколько я понимаю.

Если вам нужно крутое имя для этого подхода, как насчет того, чтобы назвать его HEX! (сокращение от H.E.C.S.)

#UseThePlatform

Веб-разработка без фреймворка

Содержание

• Что такое фреймворк?
• Нужны ли фреймворки?
• Что нам нужно
  • Безопасность
  • Государственное управление
  • Маршрутизация
  • просмотров/рендеринга
  • Постоянство
  • Исходный язык и сборка
• Библиотеки
• Проект и демонстрация

Введение

Как однажды умолял президент Кеннеди:

«Мои коллеги-разработчики, не спрашивайте, что ваш фреймворк может сделать для вас .
Спросите, что вы можете сделать для своего фреймворка!».

Да, я знаю, не , а точная цитата. Но иногда кажется, что вам нужно сделать больше, чтобы помочь вашему фреймворку работать, чем ваш фреймворк, чтобы помочь вам.

Два года назад я работал с Angular 2, и если вам удавалось получить сжатую полезную нагрузку javascript менее 200 КБ, вы думали, что у вас все хорошо. Я вспомнил об этом, когда понял, что теперь у меня может быть приложение с гораздо большей функциональностью и легко в пределах 15 КБ.

Может быть, пришло время спросить себя, что ваш фреймворк действительно делает для вас… и нужен ли он вам?

Что такое фреймворк?

Прежде всего, давайте проясним, что мы подразумеваем под цифрой 9.0003 рамки . Для меня фреймворк воплощает некоторую архитектуру приложения, и, если вы правильно заполните нужные части, он вызовет ваш код и заставит его работать. Но главное — структура, и вы работаете так, как диктует и . Фреймворки могут быть великолепны, когда вы начинаете, потому что они предоставляют некоторую структуру, которую вы, возможно, не знаете, как построить самостоятельно, но если вы не возражаете против «требуется некоторая сборка», тогда библиотеки обеспечивают гораздо большую гибкость и меньшую блокировку. Теоретически вы можете выбрать библиотеки, которые хотите использовать, и заменить любую из них по мере необходимости, если появится что-то лучшее. Вы можете рассматривать фреймворк как готовую группу библиотек, но фреймворк устанавливает правила.

Нужны ли по-прежнему фреймворки?

Но времена меняются. Точно так же, как jQuery сделал совершенным смыслом и предоставил ценные абстракции для маскировки несметного количества несоответствий браузеров, но стал менее ценным сейчас, когда все стало более стандартизированным, так и слишком многие функции, предоставляемые фреймворками, уже не так необходимы, как браузеры. имеют возможности, встроенные напрямую.

Какой бы фреймворк вы ни использовали, легко попасть в ловушку, предполагая, что он нужен, но причины, по которым он был нужен около двух с лишним лет назад или когда вы начали его использовать, могут больше не применяться или быть недействительными. Платформа браузера постоянно развивается, поэтому полезно время от времени пересматривать свой выбор, чтобы убедиться, что он нам по-прежнему нужен, и мы используем его не только потому, что он стал удобным одеялом, с которым мы знакомы.

Подумайте об этом, представьте, что в вашем браузере уже есть встроенная веб-инфраструктура, разработанная в собственном коде, быстрая и ничего лишнего для загрузки. Разве вы, , не хотели бы, чтобы использовал его? Или подумайте об этом с другой стороны, если бы вы уже использовали встроенный фреймворк, вы бы действительно «купились» на идею добавления дополнительных 100 КБ JavaScript в ваше приложение только для того, чтобы делать то, что оно уже может делать, с немного другим API? Добавляет ли он достаточную ценность, чтобы оправдать затраты?

Вместо этого мы можем использовать саму платформу, когда это возможно, и, где это имеет смысл, использовать библиотеки, чтобы сделать использование этой платформы немного проще и удобнее, если они не слишком дорого стоят с точки зрения производительности и шагают камни к тому, что платформа может принять в будущем.

Что нам нужно

Есть еще вещи, которые нам нужны и которые имеет смысл повторно использовать в проектах, а не изобретать и повторно реализовывать для каждого из них, поэтому я, конечно, не выступаю за отсутствие каких-либо зависимостей, но это полезно относитесь к ним как к библиотекам, которые нам нужны для выполнения конкретных задач. Итак, давайте рассмотрим основные части и варианты использования библиотек для обеспечения необходимой нам функциональности и способы их объединения.

Это личный список, основанный на том, что я использую для своей разработки, хотя вы должны иметь возможность заменить части тем, что вам нужно.

Безопасность

Если у вас есть веб-приложение, у вас есть пользователи, и вам необходимо их аутентифицировать. Если нет, то у вас просто статический веб-сайт, поэтому перестаньте все усложнять и просто используйте свою любимую CMS или генератор сайтов, такой как Jekyll или Hugo, или напишите свой собственный.

Я большой поклонник аутентификации Firebase, потому что она «дешевая как чипсы», отлично работает и очень проста в использовании. Так что я использую это, но вы можете подключить любую другую систему аутентификации, которую вы используете вместо этого.

Государственное управление

Двусторонняя привязка данных раньше была в моде, но как подход она действительно потеряла популярность и вымирает (как эволюционный тупик). Как только вы почувствуете преимущества односторонних / неизменяемых потоков данных с использованием чего-то вроде Redux, вы никогда не вернетесь назад. Так что используйте Redux и научитесь правильно его использовать — это стоит вложений.

Хотя есть альтернативы, стоит помнить, что для Redux существует целая экосистема инструментов и библиотек. Мы будем использовать некоторые из распространенных, чтобы упростить обработку удаленных вызовов API и других асинхронных действий, а также некоторые связанные библиотеки для эффективного создания представлений данных в нашем магазине.

Маршрутизация

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

Активный вид и параметры для него — это просто состояние, как и любое другое, и это состояние должно быть в магазине Redux. Если мы используем промежуточное ПО для синхронизации хранилища Redux с адресной строкой браузера, наше приложение может просто работать из этого состояния.

Представления / Рендеринг

Мы хотим, чтобы наши представления были инкапсулированными компонентами, а для этого требуются две вещи — компоненты или классы и некоторый способ их преобразования в HTML для отображения в браузере. К счастью, стандарт WebComponents теперь предоставляет систему компонентов, изначально встроенную в браузер, с методами жизненного цикла, к которым мы можем подключиться. Так что остается только рендеринг нашего состояния через компоненты в HTML. Хотя мы могли бы сами кодировать манипулирование DOM, это одна из тех частей, которые можно сделать универсальными, и в городе есть новая игра для шаблонов HTML-представлений под названием Lit-Html.

TL;DR; Lit-Html позволяет вам определить HTML-шаблон как специальный тип «помеченной» строки, а затем может заменять переменные в нем всякий раз, когда эти переменные изменяются, но очень эффективно, поэтому не нужно тратить время на обновление каких-либо частей, которые не изменились.

Думайте об этом как о DOM-диффинге React, но без какого-либо сравнения — проверьте это сравнительное сравнение производительности фреймворка javascript, которое показывает, что это быстро.

Persistence

Раньше это означало бэкэнд JSON REST API, но крутые ребята будут смеяться над нами, если мы не «бессерверные», и, по правде говоря, бессерверные действительно удобны, и поскольку мы используем Firebase для аутентификации, мы также можем использовать Firebase для хранилища данных.

Возможно, вы слышали или уже пробовали базу данных Firebase Realtime, но есть и более новая база данных Firestore, которая как бы объединяет RTDB с хранилищем данных Google Cloud Platform и обеспечивает более красивую структуру ваших данных (по сравнению с «большим документом JSON»). ” из RTDB), сохраняя при этом возможности синхронизации данных в реальном времени и даже добавляя некоторые приятные автономные возможности из коробки. Это также может быть значительно дешевле и обеспечивает более простые/богатые запросы (это будет очень знакомо, если вы использовали Google Cloud Datastore)

Исходный язык и сборка

Многие фреймворки предоставляют интерфейс командной строки для создания приложения, поэтому нам тоже понадобится что-то для создания нашего. Хотя мы могли бы использовать для этого модули JavaScript и ES, использование TypeScript дает много преимуществ — мы получаем хороший интеллект из-за статической типизации, и он выполняет транспиляцию в JavaScript, который может работать в браузере, поэтому мы можем использовать более новый язык.