Является ли ZEIT маяком в нашу темную эпоху веб-разработки?

Является ли ZEIT маяком в нашу темную эпоху веб-разработки?

jQuery, WordPress и PHP больше не считаются крутыми веб-технологиями, но они по-прежнему являются незамедлительными и понятными инструментами, если вам нужно быстро спроектировать, разработать и опубликовать веб-сайт или блог. Эта концепция недалеко от того, что Rails сделал и до сих пор делает для веб-приложений.

Объединив Rails, который представляет собой скорее методологию веб-разработки, чем простой фреймворк, с удобным для разработчиков решением для развертывания, таким как Heroku, вы сможете понять, почему многие успешные приложения начинались именно таким образом.

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

Шаг назад

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

В то же время, как разработчики, мы забываем, что мы тоже люди, и, как это бывает с конечными пользователями, нам нужны оперативность и хорошо продуманные инструменты с четкими правилами и подсказками, чтобы быть продуктивными. Если верно то, что JavaScript процветает в процветающей экосистеме, которая дает нам свободу выбора и безграничные возможности, верно также и то, что для каждого - даже простого - нового проекта мы должны тратить драгоценное время и энергию на то, чтобы вырезать постоянно растущий совокупность альтернатив и методов. Это означает, что, даже если мы живем в середине времени JavaScript, вероятно, у нас еще нет нашего WordPress и наших Rails.

Следующий проект JavaScript

Next.js - это небольшой фреймворк для универсальных веб-приложений на JavaScript, построенных на основе React, Webpack и Babel ¹. Может ли Next.js стать частью проекта JavaScript? В любом случае я полностью согласен с видением @rauchg, одного из его создателей:

Вот почему с помощью ZEIT мы создали Next.js. Мы думаем, что модель программирования React в сочетании с некоторыми сильными сторонами того, что дал нам «путь PHP», дадут нам очень сильное преимущество в производительности (и, следовательно, с экономической точки зрения) на долгие годы².

Оставьте задачи сборки компьютерам

Более того, Next.js оставляет за компьютером ответственность за оптимизацию, разделение и доставку ваших активов. Он абстрагирует работу Webpack, и эта задача, на мой взгляд, должна решаться автоматически с помощью фреймворков / библиотек, браузеров, сетей и протоколов, а не людьми. Честно говоря, я очень удивлен, что даже если мы часто говорим об искусственном интеллекте, применяемом в увлекательных сценариях, нам все равно приходится тратить время на ручную настройку и создание веб-ресурсов. По этому поводу я полностью согласен с @dhh и философией Rails:

Ясно то, что мы хотим, чтобы основные принципы Rails, касающиеся соглашений, преобладали над конфигурацией, были сохранены. Никто НЕ ДОЛЖЕН настраивать свой собственный webpack.config.js. Конечно, это должно быть возможно, но не обязательно .³

Если Next.js стремится упростить интерфейс разработки, Now, сервис от тех же создателей Next.js, делает то же самое для развертывания приложения. Следующие строки дают вам представление о том, что я пытаюсь аргументировать:

До сих пор в наших установках npm использовалось несколько уловок для ускорения загрузки пакетов, сильного распараллеливания и максимального сокращения дискового ввода-вывода, подобно тому, как yarn от Facebook работает сегодня.
Теперь мы это приняли. далее, путем введения глобального общего кэша общедоступных модулей, который позволяет избежать повторяющейся работы при каждом развертывании. Например, если вы развертываете узел-холст, который включает в себя длительную компиляцию C ++, наши серверы сборки делают это только один раз и безопасно передают его всем нашим клиентам.

С этим обновлением почти на каждом этапе сборки будут заметны улучшения. Если ваши проекты содержат файл npm-shrinkwrap.json или yarn.lock, вы увидите довольно резкое изменение, примерно в 2–30 раз быстрее.

Es ist Zeit

Next.js и Now - классные инструменты, они могут быть ответом на нашу усталость, и нет, я не просто продвигаю ZEIT, я пытаюсь вместо этого выделить то, что, на мой взгляд, является оригинальное сочетание библиотек и сервисов, которое может помочь разработчикам JavaScript сэкономить время и сосредоточиться на самом важном.

1. Извлечено из анонса Next.js.
2. Извлечено из ZEIT Team AMA, состоявшейся в понедельник, 30 января.
3. Извлечено из запроса на включение « Добавить поддержку Yarn в новых приложениях с помощью опции - yarn »
4 . Извлечено из Ускоренного развертывания JavaScript.