Перевод кода из интерфейсной среды JavaScript в другую.
Фронтенд-фреймворки JavaScript сейчас очень популярны и полезны для всего сообщества разработчиков JavaScript. После jQuery было создано множество фреймворков, и теперь фронтенд-инженеры могут выбирать из React, Vue.js, Ember.js, AngularJS, Svelte, Inferno и других для создания интерактивных и креативных интерфейсов, раскрывающих логику и результат свои веб-приложения конечным пользователям.
Как я подчеркивал в своей последней статье (здесь) о фреймворках JavaScript и основной метрике web vitals, выбор фреймворка JavaScript для фронтенда зависит не от навыков и воли фронтенд-инженера, а от значений, которые доставляются ему. конечные пользователи — и время, необходимое приложению, чтобы показать контент пользователю, становится одним из самых важных значений. Но как решить, какой интерфейс выбрать?
Одно из решений может состоять в том, чтобы собрать сравнительные данные о каждом фреймворке и сделать выбор, исходя из того, что данные были собраны. Эти отчеты по бенчмаркингу (кстати, бенчмаркетинг — прекрасное название) составляются такими людьми, как я, которые являются независимыми профессионалами. Но с таким решением создание доверительных отношений может быть проблемой, потому что кто знает, платит ли мне команда, стоящая за интерфейсным фреймворком JavaScript, или нет.
Второе решение для тех, у кого есть время и/или человеческие ресурсы, — создать свой интерфейс с каждым популярным интерфейсом JS и самостоятельно провести бенчмаркинг в продакшене. Затем вы можете использовать собранные данные для принятия решения о том, на какой интерфейсной платформе будет основано ваше окончательное интерфейсное решение. Но, как я уже отмечал в последнем предложении, для этого второго решения требуется много опытных фронтенд-инженеров, по крайней мере, по одному на каждый интерфейсный фреймворк. Или, если вы тот, кто может самостоятельно освоить множество интерфейсных фреймворков JavaScript, вам потребуется больше времени для разработки внешнего интерфейса с каждым фреймворком.
Это второе решение подчеркивает технологическое решение, которое может быть полезно для малобюджетных стартапов и команд разработчиков, которые не могут позволить себе много инженеров по интерфейсу или/и ограничены во времени. Это решение представляет собой оболочку, которая может принимать в качестве входных данных код данного внешнего решения, разработанного с помощью данной внешней среды JavaScript, и преобразовывать его в другой синтаксис и реализацию внешней среды JavaScript. Это не составит труда для инженера-программиста или группы, разбирающейся в том, как создаются компиляторы, потому что все это связано с грамматическим синтаксисом и зарезервированными словами.
Языковые оболочки, преобразующие код C в Java, уже успешно разрабатывались в прошлом. Другим решением может быть предложение фронтенд-инженерам языка абстрактного синтаксиса для фронтенд-разработки, который можно было бы скомпилировать в синтаксис интерфейса JavaScript, который они выбрали в качестве вывода.
Все это можно было бы добавить к работе, которую я делаю с этим компилятором нового поколения (также здесь). Интероперабельность всегда вызывала озабоченность при разработке программного обеспечения, и я думаю, что рано или поздно нам придется столкнуться с фрагментацией интерфейсных фреймворков, с которой мы сталкиваемся.
Несколько лет назад нам был нужен только DHTML, а теперь у нас есть много фреймворков для веб-разработки. Это хорошо, но передача деталей реализации инженерам и разработчикам может упростить задачу, ускорить работу и дать возможность при необходимости переходить от одного фреймворка к другому. Потому что экономия за счет масштаба и стоимости облачных вычислений может в какой-то момент в ближайшем и отдаленном будущем отдать предпочтение одному фреймворку перед другими. В таких случаях возможность переноса интерфейсной инфраструктуры будет столь же важна, как и самостоятельное выполнение функций оператора облака (я имею в виду возможность плавного перехода с AWS на GCP или Azure и наоборот).
Эти мысли касаются перспективного мышления и анализа, которые я выполняю с интерфейсными фреймворками JavaScript, и их производительности в соответствии с основными веб-жизненными показателями. Я пообещал поделиться результатами моего анализа здесь, в JavaScript на простом английском, и вы можете принять эту короткую статью и идею как сигнал, который показывает вам, что я работаю над этим перспективным анализом JavaScript-интерфейса и искренне начал писать статья, которая продемонстрирует результаты.
Если вы знаете решение, позволяющее переносить интерфейсный код из фреймворка JavaScript в фреймворк JavaScript, сообщите мне об этом. Если его нет, то это может быть интересным технологическим проектом для вас.
PS: Возможно, переводчик слов лучше, чем оболочка.
Больше контента на plainenglish.io. Подпишитесь на нашубесплатную еженедельную рассылку новостей здесь.
