Pull to refresh
137
0
Дмитрий Беляев @CuamckuyKot

веб-разработчик

Send message

Обратите внимание на пути:


PATHS.source + '/pages/index/index.pug'

Под Windows такого вида unix-пути не заработают.


Правильнее писать так:


const path = require('path');
const merge = require('webpack-merge');
const pug = require('./webpack/pug');

const common = merge([
  {
    entry: {
      'index': path.join(PATHS.source,'pages','index','index.pug'),
      'blog': path.join(PATHS.source,'pages','blog','blog.js'),
    },
    output: {
      path: PATHS.build,
      filename: path.join('.','js','[name].js'),
    },
    plugins: […],
    optimization: { … },

  },
  pug(),
]);
Для этого есть issues.

При создании запроса необходимо указать какая система, какая версия Node.JS, описать окружение в момент запуска, порядок действий.

Скопировать точно выводимые в консоли ошибки.

Будьте добры, создайте новый запрос тут:
github.com/codemotion/cogear.js/issues
Напомню, что в данном случае вообще можно не использовать фронтенд-фреймворк. Они — просто как дополнение.
Правильно! Сделайте другой тест, чтобы доказать обратное.

Тем более, что у Вас более глубокое понимание процессов, чем у автора теста.

Ладно, не моё дело — Вас убеждать в чём-либо.

jQuery и фронтент-фреймворки хоть и пересекаются по части вопросов, но из разных плоскостей.

Статистика и тренды — их не отнять. Но пусть каждый пишет на том, на чём душе угодно. И давайте закончим уже. А то какой-то холивар получается уже.
Спасибо, я вас действительно, не так понял. Возможно, и вправду построение текста было таковым.

Я вам ответил достаточно ясно по пунктам.

Ещё раз спасибо за пояснение. Я не обижался, слова принял, действительно, на свой счёт.
Спасибо, буду стараться.
Правильно. Пока нет. Намеревался закончить серию видеороликов, после чего перевести сайт и видео на русский.
Полностью согласен.

Тем более, когда фронтенд-фреймворки весят в разы меньше jQuery.

Спасибо.


Если по-английски читаете, можете посмотреть здесь:
https://dev.to/cogear/creating-a-blog-with-cogearjs-21af

На основании чего вы позволили себе такое суждение о «неполноценности»?
Да ещё бросили камень в виде «быстрой наколенной поделки».


Начнём с того, что в Open Source понятие «seller» отсутствует. Здесь ничего не покупается и не продаётся.


  1. Асинхронная сборка страниц.
  2. Горячая перезагрузка ассетов.
  3. Поддержка «из коробки» ES6, TypeScript, CoffeeScript, SASS, LESS, Stylus.
  4. Модульность, плагины.
  5. Встроенный деплой.
Согласен. Однако и с таким инструментом можно хорошо поизучать VanillaJS, ES6 и препроцессоры.

Это факт, который измеряется по числу загрузок в промежуток времени.


С точки зрения инженера работа с VirtualDOM вдвое быстрее дедовского метода jQuery:
https://github.com/jonmiles/react-performance-tests


Совершенно непредвзятое тестирование, которое каждый может проделать самостоятельно.


Думаю, что переведёте сами:


React was certainly faster the jQuery approach, in fact on average more than twice as fast. In a way that was to be expected, as jQuery has no fancy update implementation (e.g. Shadow DOM) and literally rebuilds the entire grid on each render. That said, if we're only updating 20% of the rendered elements then logically I would have expected it to be more like 5 times faster.
Речь не про замену текста в элементе. А про операции типа appendChild.

Не всю страницу, а только лишь тот блок, который Vue обрабатывает, который задаёт как el при инициализации.

Почитайте тут:
medium.com/js-dojo/whats-the-deal-with-vue-s-virtual-dom-3ed4fc0dbb20

+ к тому jQuery, как было указано выше, в несколько раз тяжелее Vue.

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

Поймите одну простую вещь, jQuery не просто так стремительно теряет свою популярность.

image
Google Trends

Если работать с ShadowDOM самому, то можно, конечно, и быстрее фремворков.

Форму обратной связи тоже можно сделать по-разному. Можно с валидацией, обработкой событий, реакцией на действия пользователей. А можно, конечно, по-простому. Всё зависит от потребностей и предпочтений.
В данном случае можно расценивать Сogear.JS как сборщик HTML, CSS и ванильного JS с возможностью шаблонизации и подключения любых сторонних библиотек.
А в остальном — просто вернитесь к этому вопросу через N лет, когда вам после полугодового перерыва захочется что-то опубликовать, а те изменения безопасности, которые вы накатили за эти полгода, сломали вам генератор.

На минутку представьте, что создатели WordPress перестали бы его обновлять лет 5 назад.


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

Всё зависит от самих разработчиков.

Кто-то считает, что изучать HTML/CSS/JS не надо, а можно довольствоваться настройкой плагинов и тем для WordPress. Другие считают иначе. Каждому своё. Нельзя ответить за всех сразу.

Странный вопрос.


Прочтите данный материал:
https://www.smashingmagazine.com/2015/11/modern-static-website-generators-next-big-thing/


Посмотрите на количество звёзд в репозиториях статических генераторов сайтов.


Может быть эта информация подскажет Вам правильный ответ.

Cogear.JS работает на актуальной версии Node.JS, а также на предыдущей (9.x).


Изменений безопасности в статических генераторах нет, т.к. в генерируемом HTML охранять нечего.


У Jekyll большой путь и компания Github за плечами. Всё ещё впереди.

Отрисовка DOM на jQuery в разы больше ресурсов требует, чем у React/Vue и иже с ними.

Information

Rating
Does not participate
Location
Санкт-Петербург и область, Россия
Date of birth
Registered
Activity