Amsterdam JSNation был прекрасным опытом, который пролил свет не только на то, как веб-технологии, доступные инженерам, помогают существующей повседневной разработке, но и на то, как веб-опыт может выглядеть через 5, 10 или 15 лет.
Вот неполный список тем, затронутых в той или иной степени во время выступлений на конференции: programming paradigms, PWAs, mobile, brain-computer interfaces, TypeScript/Flow/typing systems, WebXR, WebSpeech, software architecture/patterns, QA, e2e testing, IoT, isomorphic JS apps, team structure, graphics, game dev, service workers , _17 _...
Для однодневной конференции у AmsterdamJS было что-то для всех. Если вы искали способы улучшить свою практику разработки программного обеспечения в устоявшихся аспектах, таких как сквозное тестирование, презентация Jenn Voss включала хорошую разбивку и рекомендации Cypress, а также подходы к структурированию вашей команды в отношении QA.
Но хотя такие простые темы, как тестирование / контроль качества и конкретные фреймворки, всегда будут полезны, меня выделяло количество потенциально революционных технологий, которые поднимают голову и объясняются или демонстрируются аудитории AmsterdamJS.
Я подумал, что было бы забавно пройтись по этим технологиям и сделать опрометчивое: попытаться предсказать их влияние / принятие / сроки, а также общую картину будущего Интернета. Я упорядочиваю их примерно в порядке уменьшения количества неизвестных / меньшего риска к большему количеству неизвестных / рисков, поскольку некоторые из них уже продвинулись дальше в принятии и спецификации, чем другие.
Бессерверный / статический
Бессерверная технология существует уже некоторое время, поэтому почти несправедливо оценивать ее с точки зрения осуществимости, но она значительно набрала обороты как идея в сообществе разработчиков с выпуском и поддержкой таких инструментов, как AWS Lambda и эквиваленты. Проверьте ссылку, если вам непонятно, что это такое, но суть в том, что бессерверная технология освобождает разработчиков от управления некоторыми частями субприложений нижнего уровня, которые могут находиться на уровне сервера / в корзине DevOps.
В отличие от большинства других элементов в этом списке, бессерверные шаблоны, похоже, меньше влияют на конечный UX, более того, они служат инструментами для снижения затрат на разработку / увеличения скорости / повышения простоты. Большинство разработчиков, особенно разработчиков back-end / full-stack, очень скоро узнают или уже использовали бессерверный шаблон или уже использовали его (даже если они не называют его «бессерверным»).
PWA
Прогрессивные веб-приложения - это веб-приложения следующего уровня, в которых используются такие методы проектирования и реализации, как сервис-воркеры, манифесты на основе json и пользовательские интерфейсы на основе оболочки приложения, чтобы обеспечить поведение пользователя, подобное нативному, например, добавление значка в домашний экран телефона и более стабильная работа. Таким образом, веб-подход может помочь за счет снижения затрат на предварительные данные и общих инвестиций, требуемых от пользователей.
Я ожидаю, что в течение 2 лет многие крупные корпорации или другие организации, чьи модели извлекут выгоду из повышения уровня принятия мобильных пользователей и повышения эффективности бренда в мобильной сети, будут высокими темпами внедрения. Для меня это очевидный постепенный толчок к повышению идентичности Интернета как первоклассной платформы для всех видов приложений. Примеры прогрессивных веб-приложений.
WebAssembly
WebAssembly - одна из самых захватывающих и разрекламированных технологий последних лет. Сложно объяснить кратко, но суть в том, что он позволит вам скомпилировать такие языки, как C ++ и Rust, в целевой объект, который будет работать в средах JavaScript и позволит создавать отлаживаемые, высокопроизводительные нативные приложения.
Обещание здесь состоит в том, что WebAssembly позволит приложениям браузера, Node и, предположительно, другим средам выполнения js, таким как Deno, запускать вычислительно-ориентированный код, начиная от игр AAA и заканчивая распознаванием изображений, и предложит разработчикам такие функции, как многопоточность и более прямой доступ к памяти в js среда.
Вам нужно больше доказательств мощи WebAssembly? Щелкните здесь и измените количество скелетных моделей на 100. Сравните его между WebAssembly и JavaScript, используя раскрывающийся список, и, возможно, вы получите более интуитивное представление о возможностях этой технологии.
MVP WebAssembly уже завершен многими дополнительными функциями в активной разработке, такими как потоки, сборка мусора и поддержка модуля ECMAScript. В настоящее время гораздо проще найти доказательства концепций и демонстраций в дикой природе с помощью WebAssembly, но, судя по подробностям этой статьи из Figma, преимущества весьма существенны. При этом все еще существуют проблемы с реализацией браузера, и я ожидаю еще 1-2 года, прежде чем можно будет легко найти важные производственные приложения и часто используемые библиотеки, реализованные с использованием WebAssembly (частично или полностью).
WebXR / Gamepads API
Одна из самых спорных тем нашего времени - это жизнеспособность, сроки внедрения и платформы, задействованные в технологии интерфейса XR. На AmsterdamJS Диего Гонсалес продемонстрировал, как браузеры, такие как Samsung Internet, уже поддерживают WebXR и дополнительный браузер Gamepads API. WebXR (также известный как WebXR Device API) позволит вам переходить на веб-сайты, которые функционируют как приложения XR. (Вот видео, которое я сделал о различиях между VR, MR и AR)
Хотя упомянутые API-интерфейсы все еще изменяются в отношении деталей их реализации, они экспериментально приняты большинством основных браузеров, а такие среды разработки, как A-frame, получают много внимания с открытым исходным кодом. Я весьма оптимистичен в отношении важности 3D в сети в будущем, и WebXR помогает решить одно из самых больших препятствий в XR прямо сейчас, а именно распространение контента (за счет использования браузера и использования Интернета в качестве платформы распространения).
При этом я думаю, что все еще существует множество препятствий с точки зрения общего мнения разработчиков / дизайнеров, принятия потребителями и оборудования. Я буду искать внедрение WebXR для конкретных приложений в таких областях, как архитектура / AEC, игры и 3D-моделирование / искусство примерно через 4 года.
Последние мысли
Я думаю, мы должны задать себе вопрос: почему бы в долгосрочной перспективе не все запускать в браузере? Иными словами, почему не каждое приложение должно быть доступно по URL-адресу (или приложению браузера) и быстро исполняться на переносимой, не зависящей от ОС виртуальной машине, управляемой JavaScript / WebAssembly? Есть и будут причины, но стандартный блокировщик «браузеры просто не могут этого сделать» с каждым днем все больше исчезает.
По моим оценкам, примерно через 5 лет ограничения браузера будут (и будут восприниматься) значительно менее значительными, чем сегодня; фреймворки и шаблоны для разработки трехмерных, ресурсоемких и других более богатых нативных приложений получат более широкое распространение, особенно там, где имеет смысл использовать шаблон распространения в Интернете.
Кроме того, постепенные улучшения простых технологий, которые уже важны для Интернета, таких как фреймворки для тестирования (например, Cypress), парадигмы программирования (например, реактивное / асинхронное программирование) и PWA, повысят удобство разработки, взаимодействие с пользователем, и качество веб-разработки в целом.
Сейчас прекрасное время для написания программного обеспечения для браузера; Если вы заинтересованы в повышении уровня своей карьеры в будущем, я предлагаю уделить время изучению технологий, относящихся к вышеупомянутым пунктам, которые вы, возможно, еще не используете, например WebAssembly или WebGL. Знакомство с шаблонами проектирования и интерфейсами 3D также может оказаться полезным.
Как вы думаете, я ошибаюсь? Дайте мне знать в Твиттере. Или увидимся на AmsterdamJS в следующем году!
