Вы правы. На php в таком виде решение выглядит нелепо.
Можно переконфигурировать так, чтобы nginx смотрел сначала есть ли файл в кэше, а уж потом при отсутствии оного вызывал какой-нибудь icon.php, который бы в свою очередь сгенерировал иконку и сохранил результат в кэш:
<img src=”/icon/star-red-00ff000--green.svg”>
Как по мне, для маленькой проблемы довольно сложный процесс развертки. Стоит учесть, что фронтендом иногда занимаются специалисты, не соображающие в php или настройку nginx. Или, даже соображающие, но просто не хотящие разворачивать этот ад в каждом проекте.
На node.js решение выглядело бы интереснее. Держа шаблон svg-икноки в оперативной памяти, node выстреливала бы готовые файлы быстрее nginx, который каждый раз читает статику с диска; и плюс не нужно сохранять кэш, а в процессе разработки шаблона сайта (например, подборе цветов иконок, их толщин линий) кэш вообще не нужен. Оформить это как подключаемый middleware. Было бы интересно!
Если не трудно, опишите в чем проявляется колбас jQuery? В последний раз (уже довольно давно) на nw делал десктопное приложение. Клиентского js, как такового, я не писал. Но был подключен jQuery и Bootstrap. И, вроде бы, все bootstrap-овское работало как часы без костылей.
А я использовал mysql и mongoose как в мелких, так и в крупных проектах. И бед не знал. И мне всегда было глубоко пофигу неважно что на кросс-sql-ность (sqlite, mysql, pgsql, ...), что на кросс-nosql-ность (mongo, couchdb, redis, ...). В некоторых проектах даже использовал для разных данных оба модуля mysql и mongoose одновременно.
Собственно, простота реализации, модернизации и оптимизации!
Насчет глобального объекта — не уверен, сработает ли такой фокус. Разве если в main.js добавить свойство в тот же process, оно будет доступно в «клиентской» части? Если да — спасибо, пригодится.
На самом деле, и main.js и index.html выполняются node. Но, main.js и index.html для node — это разные модули. Совершенно справедливо, что переменные одного модуля не видны в других модулях. Иначе, подключив все нужные модули npm, мы бы получали кашу из переменных, и могли бы сломать работу, если переменные определены в разных модулях дважды.
Передавать переменные в index.html лучше через свойство global чем через свойство process. Так и логичнее, и доступ к переменной будет короче на длину "process.".
Переменная, определенная как свойство global будет доступна для всех модулей, выполняющихся после определения. Но, не стоит бояться "перегрузки" глобальных имен локальными в других модулях. Например, такое использование будет работать в штатном режиме:
Кстати, справились с той проблемой так: вместо передачи массивов как аргументов, стали объявлять эти массивы как property у объектов-контроллеров, и доступ к ним в методах осуществлялся через this. Это давало значительный прирост производительности в ходе работы с приложением.
Отвечу на один вопрос, заданный несколько раз выше, здесь.
Не помню точно, как дошел до этой практики. Уже тоже пруф найти не могу. Помню, дело было за долго до nodejs. Делали web-интерфейс на ExtJS для несложной но ёмкой БД. При активной передаче некоторых массивов описанным выше способом вешался весь браузер.
Сейчас похожее поведение может проявляться при вызовах из JS функций с кодом, например, написанных на Си.
По поводу аргументов — у меня речь шла именно про большИе массивы. Разумеется, никто не запрещает передавать небольшие объекты/массивы, например, в качестве конфига. Дело в том, что в некоторых случаях использования массивов в качестве аргументов вызова функции, доступ к данным массива осуществляется не как через ссылку на исходный массив-объект, а происходит копирование массива и доступ к данным осуществляется уже к копии массива.
Зашел на страницу статьи из-за горячего заголовка. Ожидал новую тру-практику. На деле же — просто разбор собственных полетов.
Во-первых, js-движку по барабану динамическая ли функция или не динамическая. По состоянию, важному для производительности, можно выделить откомпилированные функции и неоткомпилированные. Обычно функции компилируются при первом выполнении. Существуют и способы определения откомпилированных функций и без выполнения функции. Например, через new Function(..).
По поводу массивов. Вы правильно заметили, создание массива съедает немного производительности. Вы забыли учесть, что имеет место быть не менее трудоемкая задача — утилизация массива. В вашем же примере основная производительность тратится на постоянное изменение размера массива. По уму, размер массива надо задавать при создании. И, по возможности, следует пользоваться типизированными массивами.
Стоит также отметить, что ни в коем случае нельзя пользоваться большими массивами через замыкания или параметры вызова функций. Это переполняет стек процесса и создает немалую нагрузку на процессор.
В целом, вы правы, но мне все же интересно вычислить реальные цифры. Статье больше трех лет, по меркам nodejs — это целое поколение в эволюции скриптов node :-) Думаю, когда встанет в очередной раз этот вопрос, запилю бэнчмарки самостоятельно, может даже, напишу об этом статью на Хабр.
Понимаю, что .NET устарел. На тот момент, .NET был в самый раз.
Не уверен, но скорее всего, Delphi тоже идет в ногу со временем.
Delphi.NET — это обертка над .NET. Это не полноценная реализация .NET, а лишь провайдер, соединяющий Delphi с .NET. Это сделано для того, чтобы компоненты могли вытаскиваться на форму. В противном случае, .NET компонентами можно было пользоваться хоть на Delphi 7. Только, приходилось бы их создавать и манипулировать непосредственно из кода программы.
Давно это было, когда учился еще в школе. Вспоминаю.
По всей видимости, речь шла не о самой format.com, а о том, что можно набрать в .com-файле, что бы выполнилось что-то вроде format.com c: /q. Из рабочих инструментов Norton Commander и Turbo Pascal. А сам DOS был урезан на вредные утилиты типа format.com.
На чистом ассемблере без help-а и парсинга параметров вполне могла уместиться в килобайт.
Можно переконфигурировать так, чтобы nginx смотрел сначала есть ли файл в кэше, а уж потом при отсутствии оного вызывал какой-нибудь icon.php, который бы в свою очередь сгенерировал иконку и сохранил результат в кэш:
Как по мне, для маленькой проблемы довольно сложный процесс развертки. Стоит учесть, что фронтендом иногда занимаются специалисты, не соображающие в php или настройку nginx. Или, даже соображающие, но просто не хотящие разворачивать этот ад в каждом проекте.
На node.js решение выглядело бы интереснее. Держа шаблон svg-икноки в оперативной памяти, node выстреливала бы готовые файлы быстрее nginx, который каждый раз читает статику с диска; и плюс не нужно сохранять кэш, а в процессе разработки шаблона сайта (например, подборе цветов иконок, их толщин линий) кэш вообще не нужен. Оформить это как подключаемый middleware. Было бы интересно!
пофигуневажно что на кросс-sql-ность (sqlite, mysql, pgsql, ...), что на кросс-nosql-ность (mongo, couchdb, redis, ...). В некоторых проектах даже использовал для разных данных оба модуля mysql и mongoose одновременно.Собственно, простота реализации, модернизации и оптимизации!
<script src=""></script>.Кстати, разницы в поведении require() в main.js и index.html нет, если они находятся в одной папке.
На самом деле, и main.js и index.html выполняются node. Но, main.js и index.html для node — это разные модули. Совершенно справедливо, что переменные одного модуля не видны в других модулях. Иначе, подключив все нужные модули npm, мы бы получали кашу из переменных, и могли бы сломать работу, если переменные определены в разных модулях дважды.
Передавать переменные в index.html лучше через свойство
globalчем через свойствоprocess. Так и логичнее, и доступ к переменной будет короче на длину "process.".Переменная, определенная как свойство global будет доступна для всех модулей, выполняющихся после определения. Но, не стоит бояться "перегрузки" глобальных имен локальными в других модулях. Например, такое использование будет работать в штатном режиме:
Не помню точно, как дошел до этой практики. Уже тоже пруф найти не могу. Помню, дело было за долго до nodejs. Делали web-интерфейс на ExtJS для несложной но ёмкой БД. При активной передаче некоторых массивов описанным выше способом вешался весь браузер.
Сейчас похожее поведение может проявляться при вызовах из JS функций с кодом, например, написанных на Си.
По поводу аргументов — у меня речь шла именно про большИе массивы. Разумеется, никто не запрещает передавать небольшие объекты/массивы, например, в качестве конфига. Дело в том, что в некоторых случаях использования массивов в качестве аргументов вызова функции, доступ к данным массива осуществляется не как через ссылку на исходный массив-объект, а происходит копирование массива и доступ к данным осуществляется уже к копии массива.
Во-первых, js-движку по барабану динамическая ли функция или не динамическая. По состоянию, важному для производительности, можно выделить откомпилированные функции и неоткомпилированные. Обычно функции компилируются при первом выполнении. Существуют и способы определения откомпилированных функций и без выполнения функции. Например, через
new Function(..).По поводу массивов. Вы правильно заметили, создание массива съедает немного производительности. Вы забыли учесть, что имеет место быть не менее трудоемкая задача — утилизация массива. В вашем же примере основная производительность тратится на постоянное изменение размера массива. По уму, размер массива надо задавать при создании. И, по возможности, следует пользоваться типизированными массивами.
Стоит также отметить, что ни в коем случае нельзя пользоваться большими массивами через замыкания или параметры вызова функций. Это переполняет стек процесса и создает немалую нагрузку на процессор.
В те времена, в школе дисководы были отключены, а дома даже принтер — это уже роскошь!
Приходилось переносить .com-файлы ручками через бумажку.
Тут нужен всего-лишь hex-редактор. Программу набирали вручную, списывая код с листочка (так как дисководы были отключены).
Не уверен, но скорее всего, Delphi тоже идет в ногу со временем.
Delphi.NET — это обертка над .NET. Это не полноценная реализация .NET, а лишь провайдер, соединяющий Delphi с .NET. Это сделано для того, чтобы компоненты могли вытаскиваться на форму. В противном случае, .NET компонентами можно было пользоваться хоть на Delphi 7. Только, приходилось бы их создавать и манипулировать непосредственно из кода программы.
По всей видимости, речь шла не о самой format.com, а о том, что можно набрать в .com-файле, что бы выполнилось что-то вроде format.com c: /q. Из рабочих инструментов Norton Commander и Turbo Pascal. А сам DOS был урезан на вредные утилиты типа format.com.
На чистом ассемблере без help-а и парсинга параметров вполне могла уместиться в килобайт.