Есть задачи, которые не делают на С, потому что их разработка и отладка не выгодна ни по времени, ни по стоимости. Посмотрите на такие языки как perl, python и прочие скриптовые языки. Говоря о монстрилах тут же вспоминается и java. У каждого есть свои плюсы и минусы. И потребление ресурсов компьютера, кстати, - разменная карта. Ты либо пишешь оптимальный код и отлаживаешь на потребление ресурсов, либо пишешь быстро и оптимизаторы делают это за тебя пожирая ресурсы твоего сервера и компьютеров твоих пользователей. Кто-то может написать на С, есть время и деньги, а большинство нет вот и пишут, на чем умеют и могут себе позволить. Не вы решаете, на чём будет написан тот или иной проект и никогда не сможете, слава Богу, склад ума какой-то бамбуковый у Вас.>Спасибо, посмешил. Я то думал что модуль или влинковывается в код программы статически, если статическая линковка, или динамически вгружается из системных библиотек.
...
#include <stdio.h>
...
Кто загрузил stdio? Это программа его загрузила из кода? Нет! Это мы указали компилятору, что нам нужен такой-то модули и вуаля, он у нас есть.
А это что?
...
import javax.swing.*;
...
Здесь тоже у нас что-то линкуется? Нет. Вы прекрасно понимаете о чём я говорю, только зачем-то ломаете комедию.
> Я не понимаю какие проблемы потребовать от реализатора рантайма предоставить какой-нибудь встроенный require() или типа того. Дальше нода поищет такой файл на диске, браузер попробует утащить этот файл с сервера откуда взят скрипт и проч. Какие проблемы?!
Проблемы в том, что нода не единственная такая вся неповторимая, и она еще и чисто серверная. И на клиенте уж лучше использовать define. Вот тут можно почитать: https://github.com/amdjs/amdjs-api/wiki/AMD https://github.com/amdjs/amdjs-api/wiki/require
Я уже не говорю, что require - синхронная функция, а AMD - асинхронный механизм. Причем вы можете пользоваться require из AMD-API. И как вы вообще представляете единую реализацию волшебного единого для всего 'require', если в одном случае это синхронная функция возвращающая объект, а в другом у тебя код в callback или промис. Это же синтаксически невозможно. Ну хочешь переименуй define и напиши своё API, реализующее asynchronous module definition.
>вебмартышкам
Ой, всё! Вот только не надо давать качественные суждения по целой отрасли в которой вы не в зуб ногой. Например, судя по вашему комментарию выше у вас нет понимания что клиентский и серверный JS похожи только синтаксисом и различаются в семантике. И вот доказательство:
> Вот реально - распаковка буфера в LZMA что на сервере что на клиенте одинаковая и что-то типа require("lzma") было бы логично, не?
Не! На сервере надо работаеть с LZMA через бинарную библиотеку с биндингами к JS, для скорости. На клиенте использовать реализацию написанную на JS, т.к. никто не даст вам выполнить код вне браузера. Причем там не будет общего кода, даже близко! Сама попытка использовать один и тот же код и на сервере и на клиенте для этой задачи - признак непрофессионализма.
Давайте уже отделим мухи от котлет. Есть 2 javascript-а. Один серверный, с реализацией в виде nodejs, второй клиентский в браузере. Синтаксис там одинаковый, но подходы нужно использовать разные.
В вебе вы не дотягиваете даже до мартышки, потому что пока не перечислили реальные проблемы JS и node, а их полно. Когда следующий раз будете пытаться набрасывать на JS изучите сложности, например, с асинхронным IO и c реализацией параллельных вычислений. А еще лучше попробуйте из материнского процесса собрать данные из нескольких дочек, работающих асинхронно, не завершая их. Вот где реальные грабли, хотя это проблемы именно nodejs, а не JS в целом. А все ваши печальные потуги надавить на загрузку библиотек упираются лишь в ваше непонимание разницы между сервером и кастрированным клиентом внутри браузера. И, кстати, ничьи чувства вы не обижаете.
