Зачем нужны веб-фреймворки и как обойтись без них
В этой статье подробно рассматривается несколько технических возможностей, которые являются общими для всех фреймворков. Объясняется как они реализуются в различных фреймворках и какова стоимость их применения.
Недавно меня сильно заинтересовало сравнение фреймворков с ванильным JavaScript. Это началось после некоторого разочарования, которое я испытал, используя React в некоторых из моих внештатных проектов. И с моим недавним, более близким знакомством с веб-стандартами в качестве редактора спецификаций.
Мне было интересно узнать, в чём сходства и различия между фреймворками. Что может предложить веб-платформа в качестве более компактной альтернативы и достаточно ли этого. Моя цель не в том, чтобы критиковать фреймворки, а в том, чтобы понять затраты и выгоды. Определить, существует ли альтернатива и увидеть, можем ли мы извлечь из неё уроки, даже если мы решили использовать фреймворк.
В первой части я подробно расскажу о нескольких технических функциях, общих для разных фреймворков, и о том, как они реализованы в разных фреймворках. Я также рассмотрю стоимость использования этих фреймворков.
Фреймворки
Я выбрал четыре фреймворка: React — доминирующий, на текущий момент, и три новых претендента утверждающих, что делают разные вещи иначе, чем React.
- React — React позволяет безболезненно создавать интерактивные пользовательские интерфейсы. Декларативные представления делают ваш код более предсказуемым и простым в отладке.
- SolidJS — Solid следует той же философии, что и React… Однако, у него совершенно другая реализация, которая отказывается от использования виртуального DOM.
- Svelte — Svelte это радикально новый подход к созданию пользовательских интерфейсов… этап компиляции, который происходит про создании приложения. Вместо использования таких методов, как сравнение виртуальных DOM, Svelte пишет код, который хирургически обновляет DOM при изменении состояния вашего приложения.
- Lit — Основываясь на стандартных Веб Компонентах, Lit добавляет только… реактивность, декларативные шаблоны и несколько продуманных возможностей.
Подводя итог тому, что фреймворки говорят о своих дифференциаторах:
- React — упрощает создание пользовательских интерфейсов с помощью декларативных представлений.
- SolidJS — следует философии React, но использует другую технику.
- Svelte — использует подход к пользовательскому интерфейсу на этапе компиляции.
- Lit — использует существующие стандарты с некоторыми дополнительными легковесными возможностями
Что фреймворки делают
В самих фреймворках упоминаются слова декларативный, реактивный и виртуальный DOM. Давайте разберёмся, что они означают.
Декларативное программирование
Декларативное программирование — парадигма, в которой логика определяется без указания потока управления. Мы описываем, каким должен быть результат, а не какие шаги приведут нас к нему.
На заре декларативных фреймворков, примерно в 2010 году, API-интерфейсы DOM были намного более простыми и многословными, а для написания веб-приложений с императивным JavaScript требовалось много шаблонного кода. Именно тогда концепция «Model-View-ViewModel» (MVVM) стала распространённой с новаторскими фреймворками Knockout и AngularJS, представляющими декларативный уровень JavaScript, который справлялся с этой сложностью внутри библиотек.
MVVM сегодня не является широко используемым термином, и это своего рода вариация более старого термина привязка данных .
Привязка данных
Привязка данных — декларативный способ выражения того, как данные синхронизируются между моделью и пользовательским интерфейсом.
Все популярные UI-фреймворки представляют ту или иную форму привязки данных, и их руководства начинаются с примера привязки данных.
Вот привязка данных в JSX (SolidJS и React):
function HelloWorld()
const name = "Solid or React";
return (
div>Hello name>!/div>
)
>
Привязка данных в Lit:
class HelloWorld extends LitElement
@property()
name = 'lit';
render()
return html`Hello
$this.name>!`;
>
>
Привязка данных в Svelte:
script>
let name = 'world';
/script>
h1>Hello name>!/h1>
Реактивность
Реактивность — декларативный способ выражения распространения изменений.
Когда у нас есть способ декларативно выразить привязку данных, нам нужен эффективный способ распространения изменений в структуре.
Движок React сравнивает результаты рендеринга с предыдущим результатом и при меняет разницу к DOM. Этот способ распространения изменений называется виртуальный DOM.
В SolidJS это делается более явно, с его хранилищем и встроенными элементами. Например, элемент Show будет отслеживать внутренние изменения, а не виртуальны DOM.
В Svelte генерируется реактивный код. Svelte знает, какие события могут вызвать изменение, и генерирует простой код, который проводит линию между событием и изменением DOM.
В Lit реактивность достигается с помощью свойств элемента, в основном полагаясь на встроенную реактивность пользовательских элементов HTML.
Логика
Когда фреймворк предоставляет декларативный интерфейс для привязки данных с реализацией реактивности, он также должен предоставить какой-то способ выражения некоторой логики, которая традиционно пишется в императивно. Базовыми строительными блоками логики являются if и for «, и все основные фреймворки в той или иной степени предоставляют эти строительные блоки.
Условные выражения
Помимо привязки основных данных, таких как числа и строки, каждый фреймворк предоставляет условный примитив. В React это выглядит так:
const [hasError, setHasError] = useState(false);
return hasError ? label>Message/label> : null;
…
setHasError(true);
SolidJS предоставляет встроенный условный компонент Show :
Show when=state.error>>
label>Message/label>
/Show>
Svelte предоставляет директиву #if :
#if state.error>
label>Message/label>
/if>
В Lit вы можете использовать тернарную операцию в функции render :
render()
return this.error ? html``: null;
>
Списки
Другим распространённым примитивом фреймворка является обработка списка. Списки являются ключевой часть пользовательского интерфейса — список контактов, уведомлений и т.д. И для эффективной работы они должны быть реактивными, а не обновлять весь список при изменении одного элемента.
В React обработка списка выглядит так:
contacts.map((contact, index) =>
li key=index>>
contact.name>
/li>)
React использует специальный атрибут key , что бы различать элементы списка, и гарантирует, что весь список не заменяется при каждом рендеринге.
В SolidJS используются встроенные элементы for и index :
For each=state.contacts>>
contact => DIV>contact.name>/DIV> >
/For>
Внутри SolidJS используется собственной хранилище в сочетании с for и index , чтобы решить, какие элементы обновлять при изменении элементов списка. Он более понятен, чем React, что позволяет избежать сложности виртуального DOM.
Svelte используете директиву each , которая переносится на основе своих обновлений:
#each contacts as contact>
div>contact.name>/div>
/each>
Lit предоставляет функцию repeat , которая работает аналогично отображению списка на основе key в React:
repeat(contacts, contact => contact.id,
(contact, index) => html` $contact.name > `
Компонентная модель
Одна вещь, которая выходит за рамки этой статьи — компонентная модель в различных фреймворках и то, как она может быть решена с помощью пользовательских элементов HTML.
Примечание: Это большая тема, и я надеюсь охватить её в будущей статье, потому что эта статья станет слишком длинной. 🙂
Цена
Фреймворки обеспечивают декларативную привязку данных, примитивы потока управления (условные выражения и списки) и реактивный механизм распространения изменений.
Они так же обеспечивают другие важные моменты, такие как повторное использование компонентов, но это тема для отдельной статьи.
Фреймворки полезны? Да. Они дают нам эти удобные функции. Но правильно ли задавать этот вопрос? Использование фреймворка сопряжено с определёнными затратами. Давайте посмотрим какова цена их использования.
Размер пакета
При взгляде на размеры пакета, мне нравится смотреть на минимизированные не сжатый Gzip размер. Этот размер, является наиболее актуальным для вычисления стоимости затрат CPU на выполнение JavaScript.
- ReactDOM около 120 КБ.
- SolidJS около 18 КБ.
- Lit около 16 КБ.
- Svelte около 2 КБ, но размер сгенерированного кода варьируется.
Похоже, что сегодняшние фреймворки справляются с задачей сохранения небольшого размера лучше, чем React. Виртуальный DOM требует большое количество JavaScript кода.
Сборка
Каким-то образом мы привыкли собирать наши веб-приложения. Невозможно начать фронтенд проект без настройки Node.js и бандлера, такого как Webpack, имеющего дело с некоторыми недавними изменениями конфигурации в стартовом пакете Babel-TypeScript и всем этим джазом.
Чем выразительнее и меньше разер пакета, тем больше нагрузка на инструменты сборки и время транспиляции.
Svelte утверждает, что виртуальный DOM — это чистые накладные расходы. Я согласен, но, возможно сборка (как в случае с Svelte и SolidJS) и пользовательские механизмы шаблонов на стороне клиента (как в случае с Lit) также являются чистыми накладными расходами другого рода?
Отладка
Со сборкой и транспиляцией появляется новый тип расходов.
Код который мы видим, когда используем или отлаживаем, значительно отличается от того, что мы написали. Теперь мы полагаемся на специальные инструменты отладки различного качества, что бы перепроектировать то, что происходит на веб-сайте, и связать это с ошибками в нашем собственном коде.
В React вызов стека никогда не бывает вашим — React обрабатывает события за вас. Это отлично работает когда нет ошибок. Но попробуйте определить причину бесконечного цикла повторной отрисовки и вас ждёт мир боли.
В Svelte размер пакета библиотеки маленький, но вы собираетесь отправлять и отлаживать целую кучу загадочного сгенерированного кода, который является реализацией реактивности Svelte, адаптированной к потребностям вашего приложения.
В случае с Lit речь идёт не столько о создании, сколько о том, что для эффективной отладки вы должны понимать механизм работы его движка шаблонов. Возможно, это главная причина, по которой я скептически отношусь к фреймворкам.
Когда вы ищите пользовательские декларативные решения, в конечном итоге вы сталкиваетесь с более болезненной императивной отладкой. Примеры в этом документе используют TypeScript для спецификации API, но сам код не требует транспирации.
Обновления
В этой статье я рассмотрел четыре фреймворка, но их гораздо больше (AngularJS, Ember.js, и Vue.js, ещё несколько из них). Можете ли вы рассчитывать на то, что фреймворк, его разработчики, и его экосистема будут работать на вас по мере его развития?
Одна вещь которая вызывает большее разочарование, чем исправление ваших ошибок — поиск обходных путей ошибок фреймворка. И ещё одна вещь, которая расстраивает сильнее ошибок фреймворка — ошибки возникающие после обновления фреймворка без изменений вашего кода.
Правда, эта проблема также существует и в браузерах, но когда это происходит, это происходит со всеми, и в большинстве случаев немедленно исправляется или публикуется способ решения проблемы. Кроме того, большинство шаблонов опубликованных в этой статье основаны на API зрелых веб-платформ; не всегда нужно идти по самому краю.
Итог
Мы немного углубились в понимание основных проблем, которые пытаются решать фреймворки, и того, как они их решают, сосредоточив внимание на привязке данных, реактивности, условных выражениях и списках. Мы так же рассмотрели стоимость использования фреймворков.
Во второй части мы увидим, как эти проблемы можно решить без использования фреймворка, и чему мы можем из этого научится. Оставайтесь на связи!
Понимание JavaScript-фреймворков для фронтенда
JavaScript-фреймворки являются неотъемлемой частью современной веб-разработки,предоставляя разработчикам проверенные и протестированныеинструменты для создания масштабируемых и интерактивных веб-приложений. Многиесовременные компании используют фреймворки для своих решений, поэтому многие задачи связанные с разработкой клиентской части веб-приложений теперь требуют опыта работы с ними.
Начинающему разработчику веб-интерфейсов, может быть трудно понять, с чего начать изучение фреймворков — их выбор разнообразен, а новые появляются постоянно. В основном же они работают аналогичным образом, но делают некоторые вещи по-разному, также есть некоторые специфичные вещи, которые следует соблюдать при использовании фреймворков.
Этим набором статей мы постараемся дать вам удобную отправную точку, чтобы помочь вам начать изучать основы. Мы не стремимся научить вас всему, что вам нужно знать о React / ReactDOM, или Vue, или какой-то другой конкретной среде; Документация этих фреймворков отлично выполняют эту работу. Вместо этого мы хотим сделать шаг назад и сначала ответить на более фундаментальные вопросы, такие как:
- Почему я должен использовать фреймворк? Какие проблемы он решит?
- Какие вопросы я должен задать себе при выборе определённого фреймворка? Нужен ли мне какой-либо из них вовсе?
- Какими возможностями обладают фреймворки? Как они работают в целом и в чём отличия их имплементаций этих возможностей?
- Как они связаны с «ванильным» JavaScript, или HTML?
После этого мы предоставим некоторые учебные пособия, охватывающие основы некоторых фреймворков, чтобы предоставить вам достаточно контекста, чтобы вы могли начать углубляться в этой теме. Мы хотим, чтобы вы изучали фреймворки прагматично, не забывая о фундаментальных практиках веб-разработки, таких как, например, доступность.
Prerequisites
You should really learn the basics of the core web languages first before attempting to move on to learning client-side frameworks — HTML, CSS, and especially JavaScript.
Your code will be richer and more professional as a result, and you’ll be able to troubleshoot problems with more confidence if you understand the fundamental web platform features that the frameworks are building on top of.
Introductory guides
We begin our look at frameworks with a general overview of the area, looking at a brief history of JavaScript and frameworks, why frameworks exist and what they give us, how to start thinking about choosing a framework to learn, and what alternatives there are to client-side frameworks.
Each major JavaScript framework has a different approach to updating the DOM, handling browser events, and providing an enjoyable developer experience. This article will explore the main features of «the big 4» frameworks, looking at how frameworks tend to work from a high level, and the differences between them.
React tutorials
Примечание: React tutorials last tested in May 2020, with React/ReactDOM 16.13.1 and create-react-app 3.4.1.
If you need to check your code against our version, you can find a finished version of the sample React app code in our todo-react repository. For a running live version, see https://mdn.github.io/todo-react-build/.
In this article we will say hello to React. We’ll discover a little bit of detail about its background and use cases, set up a basic React toolchain on our local computer, and create and play with a simple starter app, learning a bit about how React works in the process.
Let’s say that we’ve been tasked with creating a proof-of-concept in React – an app that allows users to add, edit, and delete tasks they want to work on, and also mark tasks as complete without deleting them. This article will walk you through putting the basic App component structure and styling in place, ready for individual component definition and interactivity, which we’ll add later.
At this point, our app is a monolith. Before we can make it do things, we need to break it apart into manageable, descriptive components. React doesn’t have any hard rules for what is and isn’t a component – that’s up to you! In this article we will show you a sensible way to break our app up into components.
With our component plan worked out, it’s now time to start updating our app from a completely static UI to one that actually allows us to interact and change things. In this article we’ll do this, digging into events and state along the way.
As we near the end of our React journey (for now at least), we’ll add the finishing touches to the main areas of functionality in our Todo list app. This includes allowing you to edit existing tasks, and filtering the list of tasks between all, completed, and incomplete tasks. We’ll look at conditional UI rendering along the way.
In our final tutorial article, we’ll focus on (pun intended) accessibility, including focus management in React, which can improve usability and reduce confusion for both keyboard-only and screenreader users.
Our final article provides you with a list of React resources that you can use to go further in your learning.
Ember tutorials
Примечание: Ember tutorials last tested in May 2020, with Ember/Ember CLI version 3.18.0.
If you need to check your code against our version, you can find a finished version of the sample Ember app code in the ember-todomvc-tutorial repository. For a running live version, see https://nullvoxpopuli.github.io/ember-todomvc-tutorial/ (this also includes a few additional features not covered in the tutorial).
In our first Ember article we will look at how Ember works and what it’s useful for, install the Ember toolchain locally, create a sample app, and then do some initial setup to get it ready for development.
In this article we’ll get right on with planning out the structure of our TodoMVC Ember app, adding in the HTML for it, and then breaking that HTML structure into components.
At this point we’ll start adding some interactivity to our app, providing the ability to add and display new todo items. Along the way, we’ll look at using events in Ember, creating component classes to contain JavaScript code to control interactive features, and setting up a service to keep track of the data state of our app.
Now it’s time to start tackling the footer functionality in our app. Here we’ll get the todo counter to update to show the correct number of todos still to complete, and correctly apply styling to completed todos (i.e. where the checkbox has been checked). We’ll also wire up our «Clear completed» button. Along the way, we’ll learn about using conditional rendering in our templates.
In this article we learn about routing, or URL-based filtering as it is sometimes referred to. We’ll use it to provide a unique URL for each of the three todo views — «All», «Active», and «Completed».
Our final Ember article provides you with a list of resources that you can use to go further in your learning, plus some useful troubleshooting and other information.
Vue tutorials
Примечание: Vue tutorials last tested in May 2020, with Vue 2.6.11.
If you need to check your code against our version, you can find a finished version of the sample Vue app code in our todo-vue repository. For a running live version, see https://mdn.github.io/todo-vue/dist/.
Now let’s introduce Vue, the third of our frameworks. In this article we’ll look at a little bit of Vue background, learn how to install it and create a new project, study the high-level structure of the whole project and an individual component, see how to run the project locally, and get it prepared to start building our example.
Now it’s time to dive deeper into Vue, and create our own custom component — we’ll start by creating a component to represent each item in the todo list. Along the way, we’ll learn about a few important concepts such as calling components inside other components, passing data to them via props, and saving data state.
At this point we’ve got a fully working component; we’re now ready to add multiple ToDoItem components to our App. In this artcle we’ll look at adding a set of todo item data to our App.vue component, which we’ll then loop through and display inside ToDoItem components using the v-for directive.
We now have sample data in place, and a loop that takes each bit of data and renders it inside a ToDoItem in our app. What we really need next is the ability to allow our users to enter their own todo items into the app, and for that we’ll need a text , an event to fire when the data is submitted, a method to fire upon submission to add the data and rerender the list, and a model to control the data. This is what we’ll cover in this article.
The time has finally come to make our app look a bit nicer. In this article we’ll explore the different ways of styling Vue components with CSS.
In this article we’ll add a counter that displays the number of completed todo items, using a feature of Vue called computed properties. These work similarly to methods, but only re-run when one of their dependencies changes.
Now it is time to add one of the major parts of functionality that we’re still missing — the ability to edit existing todo items. To do this, we will take advantage of Vue’s conditional rendering capabilities — namely v-if and v-else — to allow us to toggle between the existing todo item view, and an edit view where you can update todo item labels. We’ll also look at adding functionality to delete todo items.
We are nearly done with Vue. The last bit of functionality to look at is focus management, or put another way, how we can improve our app’s keyboard accessibility. We’ll look at using Vue refs to handle this — an advanced feature that allows you to have direct access to the underlying DOM nodes below the virtual DOM, or direct access from one component to the internal DOM structure of a child component.
Now we’ll round off our study of Vue by giving you a list of resources that you can use to go further in your learning, plus some other useful tips.
Which frameworks did we choose?
We are publishing our initial set of articles with guides focusing on three of the major frameworks out there — React/ReactDOM, Ember, and Vue. There is a variety of reasons for this:
- They are popular choices that will be around for a while — like with any software tool, it is good to stick with actively-developed choices that are likely to not be discontinued next week, and which will be desirable additions to your skillset when looking for a job.
- They have strong communities and good documentation. It is very important to be able to get help with learning a complex subject, especially when you are just starting out.
- We don’t have the resources to cover all modern frameworks. That list would be very difficult to keep up-to-date anyway, as new ones appear all the time.
- As a beginner, trying to choose what to focus on out of the huge number of choices available is a very real problem. Keeping the list short is therefore helpful.
We want to say this up front — we’ve not chosen the frameworks we are focusing on because we think they are the best, or because we endorse them in any way. We just think they score highly on the above criteria.
Note that we were hoping to have more frameworks included upon intial publication, but we decided to release the content and then add more framework guides later, rather than delay it longer. If your favourite framework is not represented in this content and you’d like to help change that, feel free to discuss it with us! Get in touch with us via Matrix, or Discourse, or drop us a mail on the mdn-admins list.
Found a content problem with this page?
- Edit the page on GitHub.
- Report the content issue.
- View the source on GitHub.
This page was last modified on 3 авг. 2023 г. by MDN contributors.
Для чего нужны javascript-фреймворки
В последнее время всё больше шума вокруг js-фреймворков React, Angular и Vue. Порой складывается впечатление, что без этих библиотек веб-разработка уже не существует и единственный верный путь — бросать «никому не нужный» PHP, и срочно изучать реакт, поскольку он сейчас самый якобы востребованный на рынке. 🙂
Бум вокруг JS в общем-то понятен — это язык имеет довольно низкий порог вхождения, поэтому появляется всё больше «специалистов», которые прошли курсы по JavaScript, хотя полноценно не осилили ни HTML, ни CSS, а PHP для таких — просто ругательство. Почему я обращаю внимание на этот момент? Всё из-за того, что в этом шуме-буме, на самом деле есть несколько интересных и полезных вещей, на которые стоило бы обратить внимание веб-разработчику. Но из-за таких горе-специалистов докопаться до сути несколько проблематично. Лично я считаю себя достаточно «продвинутым» программистом с хорошим знанием многих технологий, включая и JavaScript, но даже для меня оказалось не таким простым занятием понять реальное назначение современных js-фреймворков.
Какой javascript-фреймворк изучать в 2019 году?
Типовой вопрос, как оказалось. 🙂 Нам всегда хочется получить ясный и понятный ответ и не допустить ошибки выбора. Скажем выучишь React, а он просто не нужен: ни в работе, ни клиентам.
Реальность немного сурова: любой фреймворк нужно изучать с основ JavaScript. При этом сразу подразумевается, что уже есть хорошие знания HTML и CSS. Хорошие — это значит, что вы без проблем можете сверстать средней сложности лендинг, а лучше сделать их штук 10 на нативном HTML и CSS. Потому что не бывает сайтов без HTML и CSS.
Ну а React, Angular, Vue и даже jQuery базируются на одном и том же — языке JavaScript и вот без его знания делать просто нечего.
Что лучше: React, Angular, Vue?
Ну хорошо, пусть уже есть знания, за что браться, какой из фреймворков более продвинут?
Здесь важно понять, что все фреймворки служат для определённой цели и предлагают некую модель построения, которой придётся придерживаться. С моей точки зрения — все они примерно одного уровня сложности: все они требуют изучения с нуля, но при этом используют свой «синтаксический сахар», который, собственно, и определяет удобство пользования фреймворком. А здесь уже на вкус и цвет.
Какой легче для новичка?
На этом этапе я спотыкался несколько раз, поскольку никак не мог сообразить, что все эти js-фреймворки, хоть и написаны на JS, на самом деле не могут (просто так) работать в браузере, как это положено любому js-скрипту.
Если, например мы хотим использовать jQuery, то мы просто подключаем js-файл и все функции библиотеки доступны на странице. С js-фреймворками всё немного сложней.
Формально Vue или React позволяют подключить себя обычным js-файлом и пользоваться на странице. Но при этом, тот же React использует синтаксис JSX, что в свою очередь потянет за собой js-файл babel.min.js размером примерно 1,5Мб. ;-(
В Vue к этому вопросу подошли куда более серьёзней и там действительно можно ограничиться только подключением js-файла. И, это классно, но только ровно до того момента, пока не нужно будет разбить проект на несколько js-файлов и использовать js-команду import .
С помощью import/export можно организовать модульность js-файлов, примерно как это делается в PHP с помощью require . Но проблема в том, что браузеры до сих пор не поддерживают import (ECMAScript 6), а это значит, что придётся отказаться от модульности, что делает js-фреймворк уже не таким привлекательным.
Чтобы решить эту проблему, используются различные системы сборки проекта. Нужно понять, что привычного «просто подключил js-файл» уже недостаточно: придётся использовать специальную программу сборки. И с моей точки зрения, выигрывает тот фреймворк, который предлагает самую простую и понятную инструкцию, чтобы не заморачиваться с установкой и настройкой эти самых «сборщиков».
Если рассматривать именно с этой точки зрения, абсолютным победителем будет Vue с его Vue CLI, который не просто позволяет создать каркас, но и предоставляет страницу управления сайтом прямо в браузере (команда vue ui ).
Самое забавное, что в руководстве по Vue, наоборот не рекомендуют использовать Vue CLI, хотя именно с его помощью исчезает головная боль с настройкой приложения.
Что касается Angular, то я даже не смог его запустить. Проблема, как мне кажется в настройках node или может была какая-то старая версия, но немного повозившись, я просто плюнул на него.
Говорят, что новая gmail-почта написана именно на Angular. В принципе этого го.на уже достаточно, чтобы напрочь отбить охоту пользоваться этим фреймворком.
С React ситуация получше, спасает наверное чуть лучше документация и, главное, готовый Create React App, который может служить каркасом простого приложения. По своим возможностям он сильно уступает Vue CLI (где например можно указать url-адрес готового сайта).
Рассматривать же фреймворки с точки зрения простоты написания кода, на данном этапе не имеет смысла. Все они имеют свои особенности.
Программы-сборщики
Обычно для проекта предполагается модульная структура, то есть будет множество файлов. Поскольку import не работает в браузере, да и может использоваться «свой синтаксис», то сборщик должен будет преобразовать исходные файлы в понятный и рабочий для браузера код.
Поэтому сборщик (обычно это Webpack) должен иметь свои настройки, с которыми новичку сложно разобраться. Здесь как раз и выручает Vue CLI, который работает из коробки. Но, если стоит задача сделать как-то по другому, то придётся все настройки выполнить самостоятельно. А чтобы это сделать, нужно изучать Webpack и желательно сделать это до или параллельно с изучением js-фреймворка.
Зачем вообще нужны javascript-фреймворки
В процессе изучения я постоянно ловил себя на мысли — зачем вообще нужны все эти сложности, если можно всё спокойно сверстать на HTML/CSS и добавить jQuery (да хоть нативный JS!). Если нужны данные, то есть PHP с доступом в базе данных и много ещё чего. Зачем вообще городить всё это?
Так вот польза от этого действительно есть и на это есть как минимум две «жирные» причины.
Первая — Web-компоненты
Модульный или компонентный подход к разработке уже давным-давно используется почти везде, кроме JS. Всё, что есть сейчас в JS — на самом деле это довольно примитивные вещи. Веб-компоненты — это технология будущего, которая может изменить положение дел и привести вебсайты в разряд полноценных приложений.
Примером веб-компонента может служить тег VIDEO, который выводит довольно сложный визуальный компонент с элементами управления. То есть мы указываем лишь тег и его параметры, а браузер преобразует его в что-то более сложное.
Если не вдаваться с техническую составляющую веб-компонентов, то по сути они предоставляют разработчику возможность создавать отдельные сущности (компоненты) с помощью обычного HTML и CSS (scoped!), а программную логику писать на JavaScript.
Например нам нужно разместить jQuery-слайдер на странице. Сейчас нужно подключить js-файл, css-стили, которые при этом не должны конфликтовать с остальными стилями сайта, а также прописать код инициализации. С веб-компонентами это будет немного проще — это всего лишь какой-то специфичный html-тэг (например MY-SLIDER) и набор атрибутов-опций.
Но на сегодняшний момент, поддержка веб-компонентов слабая, поэтому единственным способом получить что-то подобное, будет предварительная сборка проекта в понятный для браузера код. И вот здесь как раз мы и подходим к вопросу — насколько js-фреймворк соответствует концепции web-компонентов.
Сразу скажу, что я не готов сделать заключение, кто из Vue, React, и Angular лучше, поскольку у меня практически нет опыта работы с ними. Если чисто субъективно, то Vue выглядит более логичным за счет использования файлов .vue — по сути это и есть «чистый» компонент.
Хотя существуют другие js-фрейморки, которые реализуют поддержку веб-компонентов.
Вторая причина — реальная поддержка сайта
Если вы захотите увидеть примеры сайтов, сделанных на React, Angular или Vue, то скорее всего это будут какие-то жалкие единицы — просто пыль по сравнению с полноценными сайтами на PHP.
Шум вокруг js-фреймворков явно не коррелирует с их реальной используемостью в веб-разработке. Так какие-же сайты делают на этих фреймворках?
Как правило это какие-то закрытые разработки под конкретного заказчика (b2b), который готов платить большие деньги за такую работу. Но суть не только в том, что клиенты, как правило плохо разбираются в технологиях, а в том, что заказчику важно не только создание проекта, но и его дальнейшая поддержка.
Если рассматривать типовой сайт на PHP, то он будет сильно завязан на исполнителя. Например, есть некий условный php-специалист Вася, который знает только Джумлу, который всё сделает, чтобы убедить клиента использовать именно эту систему. После того, как Васю всё-таки уволили, приходит Петя и предлагает всё переписать на Друпал, поскольку это же «круть!». Понятно, что смена любого «движка» ведёт за собой череду дополнительной работы и не факт, что все изменения пойдут на пользу проекту.
Сайт на PHP состоит из нескольких частей. Первая — это работа с базой данных, то есть получение выборки в виде структурированных данных. Это самая простая часть работы. Дальше данные поступают на уровень шаблона, где уже идёт формирование HTML-вывода. Здесь уже не столько php-программирование, сколько html-верстка. После этого наступает очередь CSS, чтобы привести вывод к необходимому дизайну. Если нужно изменить/добавить какой-то элемент страницы, то цикл PHP-HTML-CSS нужно будет повторять снова и снова.
Поддержка такого проекта будет заключаться в том, чтобы иметь полноценных специалистов, которые будут разбираться сразу в нескольких технологиях. И это в какой-то мере проблема кадров, поэтому нужно стараться построить сайт так, чтобы структурные части взаимодействовали друг с другом только посредством каких-то примитивных методов.
Именно этот подход и используется в js-фреймворках. На уровне PHP обеспечивается некое API, запросы к которому возвращают json-данные. Эти данные получаются в js посредством ajax, а значит js-программист может вообще не понимать как они возникли — ему дали url и пример использования, и этого уже достаточно. PHP-программисту же не нужно верстать HTML-код и даже задумываться о том, как эти данные будут выглядеть на сайте.
Сама же верстка происходит на уровне компонентов — это уже HTML и CSS с примитивными вкраплениями js.
То есть работа разделена на части, где сильно уменьшена зависимость от человеческого фактора. Если Вася окажется плохим js-программистом, то нет проблем найти таких же с десяток, поскольку профессиональные требования здесь на уровне «детского садика». Но, при этом проект продолжает работать, потому что исключены все критические зависимости. Все довольны, клиент продолжает платить деньги. 🙂
(React || Angular || Vue) vs. jQuery
На самом деле очень странная постановка вопроса, поскольку сравнивать эти фреймворки с jQuery несколько некорректно. Но если погуглить, то этот вопрос оказывается наиболее частым.
Нужно понять, что jQuery — это просто набор функций, которые собраны в одной оболочке (библиотеке). Это ничем не лучше или хуже, чем тот же Vue или React, которые представляют собой свои наборы функций.
Вопрос здесь скорее в общей идеологии. jQuery может использовать где угодно на странице и с любыми элементами. Это такой «атомарный» подход, который позволяет использовать любые элементы. JS-фреймворки же предполагают более комплексный подход и рассматривают страницу уже не как простой набор html-тэгов, а как связанные между собой компоненты. И никто не мешает использовать jQuery совместно с ними.
Существует ряд задач, который проще решить именно с помощью фреймворка, особенно если они «заточены» под эти задачи. Но точно также гораздо проще использовать готовый jQuery-плагин, вместо того, чтобы изобретать новый велосипед.
Типы сайтов для javascript-фреймворков
JS-фреймворки, в силу того, что работают на стороне клиента, не могут нормально использоваться там где много динамических данных и разных страниц/адресов, как например в блогах. Поэтому основное для них назначение — это SPA (single page application), где всё действие происходит на одной-единственной странице. И хотя уже сейчас для них существуют решения в виде роутинга, выглядит это всё равно несколько странно.
Поэтому js-фреймворки будут интересны только там, где необходима высокая «динамичность», как например в той же gmail-почте. Главная фишка тут в том, что интерфейс меняется без перезагрузки страницы и выглядит в целом как обычная программа.
Я очень сомневаюсь, что js-фреймворк следует использовать на обычных сайтах или лендингах. Как правило здесь нет потребности в множественных аякс-запросах, а значит можно легко обойтись обычным PHP/HTML/CSS/JS/jQuery.
Стоит также учесть, что эти фреймворки сильно тормозят (речь, конечно о чём-то более-менее серьёзном). Пример новой gmail-почты очень показателен — пользоваться совершенно нереально как раз именно из-за очень низкой скорости загрузки, тормозной реакции и постоянных сбоев и самоперезагрузок. Или например недавно мой банк обновил свою клиентскую часть и стал загружаться примерно 2 минуты, при том часто с ошибками. Раньше это было не так красиво, но работало раз в 100 быстрей. Думаю, что нужно учитывать этот фактор, особенно если сайт как-то завязан на бизнес.
Кроме того и SPA-приложений есть один очень существенный недостаток — плохая поддержка поисковиками. Из-за того, что страница формируется js-кодом, да ещё и по множественным аякс-запросам, то её довольно сложно нормально проиндексировать. Гугл, конечно, пытается, но очевидно, что до обычной HTML-страницы ему ещё далеко.
В заключении всё-таки отмечу, что при всех недостатках, есть несколько причин поизучать React, Angular или Vue. Первая — это просто интересно, особенно в плане будущего перехода к веб-компонентам. Полноценный сайт всё-равно не сделаешь, но для общего развития будет полезно. Вторая причина прозаическая — если «богатые буратины» готовы платить за это деньги, то почему бы и нет? Вреда от этого мало, а полученные деньги могут пригодится на что-то более стоящее. Например на платные курсы PHP. 🙂
Популярные фреймворки JavaScript
JavaScript — это мультипарадигмальный язык, который поддерживает типы программирования, управляемые событиями, функциональные и обязательные (в том числе объектно-ориентированные и основанные на прототипах). Первоначально JavaScript использовался только на стороне клиента. Теперь JavaScript еще используется в качестве языка программирования на стороне сервера. Подводя итог, можно сказать, что JavaScript является языком Интернета.
Что такое JavaScript Framework? Зачем их вообще использовать?
Фреймворки JS — это библиотеки программирования JavaScript, в которых есть предварительно написанный код для использования в стандартных функциях и задачах программирования. Это основа для создания веб-сайтов или веб-приложений вокруг.
Давайте начнем с того, зачем нам нужны фреймворки JavaScript? Кодирование вполне возможно без их использования, но правильно подобранная среда может значительно облегчить работу. Более того, они бесплатные и с открытым исходным кодом, так что нет риска.
В первую очередь это повысит вашу производительность. Рассматривайте это как своего рода обходной путь: вам придется писать меньше кода вручную, потому что уже есть заранее написанные и готовые к использованию функции и шаблоны. Некоторые компоненты веб-сайта не должны быть изготовлены по индивидуальному заказу, поэтому вы можете создавать и расширять предварительно созданные компоненты. Фреймворки более адаптируемы для дизайна веб-сайтов, и большинство разработчиков сайтов предпочитают их. Давайте посмотрим на лучшие JS Frameworks.
В настоящее время лидером в области инфраструктуры JavaScript UI является React. Сначала разработчики Facebook начали работать над этим, чтобы упростить свою работу. Приложение под названием Facebook Ads росло очень быстро, что означало сложное управление и поддержку. В результате команда начала создавать структуру, которая поможет им с эффективностью. У них был ранний прототип до 2011 года, а два года спустя, структура была с открытым исходным кодом и доступна для общественности. В настоящее время его используют многие бизнес-гиганты: AirBNB, PayPal, Netflix и т. д.
React основан на компоненте многократного использования. Проще говоря, это блоки кода, которые можно классифицировать как классы или функции. Каждый компонент представляет определенную часть страницы, такую как логотип, кнопка или поле ввода. Используемые ими параметры называются реквизитами, что означает свойства. Говоря о синтаксисе, большинство разработчиков сходятся во мнении, что React легко освоить, когда вы уже знаете JavaScript.
React использует JSX, синтаксис XML, который сочетает в себе JavaScript и HTML. Это не шаблон JavaScript; это полный JavaScript. Поначалу некоторые новые разработчики могут найти JSX немного запутанным. Однако, поработав с ним некоторое время, вы поймете, насколько это полезно. Это библиотека, на которую вы должны обратить внимание, если вы занимаетесь интерфейсной веб-разработкой. Запишись на курсы программирования React.
Angular — одна из самых мощных сред JavaScript. Google использует эту платформу для разработки одностраничного приложения (SPA). Эта среда разработки известна прежде всего потому, что она предоставляет разработчикам лучшие условия для объединения JavaScript с HTML и CSS. Более полумиллиона сайтов, таких как google.com, youtube.com и т.д., используют Angular.
Это также предпочтительная среда пользовательского интерфейса JavaScript для разработчиков приложений Google. Angular имеет компонентную структуру, как и React. Вы можете манипулировать, вкладывать и использовать их по мере необходимости. Вам нужно будет использовать TypeScript, чтобы написать приложение в Angular. Это расширенный набор JavaScript, который использует тот же синтаксис, но также поддерживает статическую типизацию и классы. В TypeScript вы получаете модификаторы доступа, перечисления, обобщения, гибридные типы и многое другое. Проще говоря, Angular — это фантастическая платформа, на которую можно взглянуть, если вы новый разработчик.
Vue — это JavaScript-фреймворк с открытым исходным кодом для создания креативного интерфейса. Интеграция с Vue в проектах, использующих другие библиотеки JavaScript, упрощена, поскольку она разработана для адаптации. Более 36 000 веб-сайтов в настоящее время используют Vue. Такие компании, как Stackoverflow, PlayStation и т.д., полагаются на Vue для своих сайтов пользовательского интерфейса.
Vue.js также довольно прост в освоении: все что нужно, это JavaScript и HTML. Другой сильной стороной Vue.js является его интерфейс командной строки (CLI). Это базовый инструмент, который ускоряет разработку, предлагая массу плагинов, пресетов, мгновенного прототипирования и интерактивного инструмента разработки проектов. Некоторые из его функций включают компоненты, шаблоны, переходы и двустороннее связывание данных, а также фокус реактивности. Реактивность возникает при изменении или обновлении любого из объектов JavaScript в Vue. Vue.js использует то, что называется Shadow DOM, что делает рендеринг страницы быстрым.
JQuery, пожалуй, самая популярная библиотека JavaScript с таким количеством функций для современной разработки. JQuery — это быстрая и лаконичная библиотека JavaScript, созданная Джоном Резигом в 2006 году. Это кроссплатформенная библиотека JavaScript, предназначенная для упрощения HTML-скриптинга на стороне клиента. Более 19 миллионов веб-сайтов в настоящее время используют jQuery! Такие компании, как WordPress, Facebook, Google, IBM и многие другие, полагаются на jQuery для обеспечения своего рода просмотра веб-страниц.
Вы можете использовать API jQuery для обработки, анимации и манипулирования событием в HTML-документе, также известном как DOM. Кроме того, jQuery используется со строительными инструментами Angular и React App. Одним словом, одна из самых важных библиотек JavaScript для веб-разработки.
5. Backbone.js
Это одна из самых популярных платформ JavaScript. Его можно использовать для создания одностраничного приложения. Разработка этого фреймворка предполагает, что все функции на стороне сервера должны проходить через API, что поможет достичь сложной функциональности за счет написания меньшего количества кода.
BackboneJS — это легкая библиотека JavaScript, которая позволяет разрабатывать и структурировать клиентские приложения, работающие в веб-браузере. В отличие от других сред, Backbone поручает разработчику выбрать правильный инструмент, который лучше всего подходит для данного проекта. Более полумиллиона сайтов в настоящее время используют Backbone, включая tumblr.com, espn.com, soundcloud.com и многие другие.
Node.js — это серверная платформа с открытым исходным кодом, созданная на основе Google Chrome JavaScript Engine. Количество сайтов, использующих NodeJS, увеличилось на 84 000. Это одна из наиболее загруженных кроссплатформенных сред выполнения для выполнения кода JavaScript. Node.js — это асинхронная, однопоточная, неблокирующая модель ввода / вывода, которая делает ее легкой и эффективной. Пакетная экосистема Node.js, npm, также является крупнейшей в мире библиотечной экосистемой с открытым исходным кодом. Запишись на курсы программирования NodeJS.
Ember.js — это JavaScript-фреймворк с открытым исходным кодом, который был первоначально выпущен Иегудой Кацем в 2011 году. Первоначально он назывался SproutCore 2.0, прежде чем стал называться Ember.js. Работа над Ember Framework началась в 2011 году, а версия 1.0 была выпущена два года спустя.
Он также отлично масштабируется и может использоваться для больших проектов. Apple Music, которая имеет более 60 миллионов подписчиков по всему миру, была построена на Ember. Если вы хотите увидеть, что вы сможете — есть инструмент под названием Ember Inspector, который позволяет вам ближе познакомиться с проектами Ember в Интернете.
В Ember есть отличный инструмент для сборки, заимствованный из многих других сред SPA, называемый Ember CLI. Этот инструмент сборки имеет все необходимое для начала работы. Вам нужен роутер? Там встроено. Нужно пройти тестирование? Он тоже встроен. Вам нужно работать с внутренними данными? Есть данные на Эмбер. Ember.js следует многим тем же принципам, что и Ruby в Rails. Он очень продуман, гибок.
Веб-фреймворк под названием Skybreak был выпущен в конце 2011 года. Через пару месяцев команда сменила название на Meteor. Используя простой JavaScript, вы можете создавать приложения, которые можно использовать на разных платформах, включая, помимо прочего, Android и iOS. Среда Meteor JS предоставляет решения с полным стеком. Использование этой инфраструктуры включает в себя важные области, такие как внутренняя разработка, управление базами данных, бизнес-логика и внешний рендеринг.
Meteor позиционирует себя как самый быстрый способ создания приложений JavaScript. Он завоевывает популярность на рынке с более чем 13 000 веб-сайтов, использующих Meteor. Такие сайты, как mtv.com, meteofrance.com и т.д., используют Meteor для создания своего пользовательского интерфейса.
Polymer- это библиотека JavaScript с открытым исходным кодом, поддерживаемая Google для создания веб-приложений с использованием веб-компонентов. Он также поддерживает как одностороннюю, так и двустороннюю привязку данных, создавая более обширную область применения. Когда вы сравниваете Angular с Polymer, поскольку оба они созданы Google, Angular представляет собой комплексную среду для разработки веб-приложений, тогда как Polymer — это всего лишь библиотека для разработки веб-компонентов. Это была первая библиотека, которая позволяла создавать интерактивные приложения с помощью веб-компонентов. В настоящее время более 3000 веб-сайтов используют Polymer, например, virustotal.com, rogers.com, zeplin.io и так далее.
10. Aurelia
Aurelia — это интерфейсная среда с открытым исходным кодом, разработанная Робом Айзенбергом. Aurelia 1.0 была выпущена впервые в 2016 году. Aurelia состоит из функционально-ориентированных модулей, таких как плагины, маршрутизация, тестирование, внедрение зависимостей и многое другое. Вы можете использовать среду Aurelia JS для разработки веб-приложений, приложений для мобильных устройств и компьютеров. Модульность также позволяет создавать приложения разных размеров. Aurelia поддерживает как Babel, так и TypeScript. Он также полностью совместим с будущими версиями JavaScript.
Из вариантов, представленных в этом руководстве, Aurelia может быть одной из самых молодых: мы получили версию 1.0 только в середине 2016 года. Однако это дает ему небольшое преимущество: по словам его создателей, Aurelia предлагает компонентную модель, которая наилучшим образом соответствует лучшим веб-стандартам. Он использует множество новых функций ECMAScript (ECMAScript помогает определять стандарты JavaScript) и рекомендует вам использовать эти новые функции для написания кода. Это хорошо, потому что вы не изучаете собственный синтаксис, который работает только с Aurelia. Проверьте это, если найдете это интересным!
Для тех из вас, кто является новичком в веб-разработке, вы услышите много циничных людей, говорящих о том, что мир JavaScript стал слишком быстрым. Они будут стонать, что новые библиотеки JavaScript и фреймворки выходят слишком быстро, и что все пытаются сделать то же самое. Они не ошибаются в том, что он быстро развивается, но это не должно помешать вам выйти и изучить эти фреймворки и библиотеки JavaScript.
