Kyubey

Lynn «Кофеман», Я вчера догадался, в чём проблема. Я работаю в Visual Studio и почему-то, когда я добавил в проект tsconfig.json, студия не заместила им собственные настройки. По сути, обычно происходит оверрайд, потому что по умолчанию студия хранит настройки компиляции в свойствах проекта, а тут этого не произошло. Естественно, когда я это понял, я сразу же решил эту проблему. Теперь у меня генерируется ES6 или ESNext код в зависимости от того, что я указываю. Поэтому спасибо вам, я бы не разобрался, что дело именно в конфиге.

Егор Живагин, вот есть релейтед вопрос на со: https://stackoverflow.com/questions/42422885/cant-... Там предлагают использовать expose-loader вебпака, но я попробовал и он не сработал, это устаревшая информация. Про сурсмапы и прочее - вы правы. Мне просто удобней дебажить оригинальные файлы. Девсервер я не поднимаю.

Lynn «Кофеман», Странно. У меня он всё равно генерирует строку

Object.defineProperty(exports, "__esModule", { value: true });

, что бы я ни делал.

Я сейчас написал класс в отдельном файле -

class Test1 {

}

export { Test1 };

и вот, что оно мне сгенерировало -

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Test1 = void 0;
var Test1 = /** @class */ (function () {
    function Test1() {
    }
    return Test1;
}());
exports.Test1 = Test1;
//# sourceMappingURL=test1.js.map

Lynn «Кофеман», Вот мой конфиг:

{
  "compileOnSave": true,
  "compilerOptions": {
    "module": "ES2015",
    "newLine": "LF",
    "outDir": "./wwwroot/app/",
    "emitBOM": true,
    "target": "ESNext",
    "sourceMap": true,
    "declaration": true,
    "lib": [
      "es2015",
      "dom"
    ],
    "strict": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "forceConsistentCasingInFileNames": false,
    "strictPropertyInitialization": false,
    "esModuleInterop": true
  },
  "include": [
    "./wwwroot/app/**/*"
  ],
  "exclude": [
    ".git",
    "node_modules"
  ]
}

MaxKorz, > Это какие?
Утечки. Я не говорю, что это вина интерпретатора или языка как такового, просто их там легче устроить, чем в семействе языков Си, например. Понятно, что они так или иначе нужны для разных задач.
> Синтетические тесты непоказательны.
Они не показательны, потому что имеют мало отношения к практике (в большинстве случаев). Однако это позволяет демонстрировать возможности языка в этих прикладных задачах. Благодаря этому иногда находятся пути оптимизировать те или иные решения, которые, к примеру, повышают количество запросов в секунду, которое способен обработать веб-сервер, написанный на этом языке (или модуль для веб-сервера, в общем, что-то, имеющее реальное применение). Но это оффтоп.
Насчёт бизнес-логики я с вами согласен.

Внезапно, действительно подходит, хотя раньше я не особо обращал на него внимание. Спасибо! Будет, с чем поработать.

> стабилен в вашей интерпретации - мертв(ибо без изменеий нет развития)
Ну почему же. Я имел в виду обратную совместимость с предыдущими версиями языка. К примеру, у C# с этим всё более-менее хорошо, в PHP7 была пара не критичных вещей относительно PHP5, но в целом терпимо, а вот Питон 3 вообще по сути другой язык, если сравнивать с 2. С либами всё понятно, тут ничего не поделаешь.
> Сложнее найти современный язык без таковой возможности...
Бывают и такие.
> ВМ и прочие накладные расходы [..] обеспечивают повышение быстродействия в кроссплатформенной среде, часто превосходя по быстродействию даже компилируемые аналоги без ВМ
Тут вы правы. Однако сложно не согласиться с тем, что чем меньше в идеале издержки на поддержку ВМ, тем лучше, не так ли? Я не требую идеала, хотел провести сравнительный анализ.
Спасибо за развёрнутый ответ :)

Насчёт первого "почему". На php я уже писал и его быстродействие совсем меня не удовлетворяет, равно как и питон, у которого к тому же проблемы с версиями (2 и 3), которых я хотел бы избежать. К тому же синтаксис питона не слишком удобен, все эти отступы, знаете ли.
Джава, на мой взгляд, компилируемый язык. Я знаю про байт-код и его интерпретацию, но это уже немного другое. В джаве бывают проблемы с памятью, например.
> Тонны легаси и проприетарщины тянет не язык, а программист.
Мы оба с вами пониманием, что я имел в виду. Вряд ли кто-то захочет писать свою имплементацию System.Web на C#, например.
> А как зависит "течь" от языка? Это зависит от криворукости программиста.
Этот фактор мы в учёт не берём, так как сейчас говорим именно о языке. Это значит лишь то, что не хотелось бы, чтобы особенности компилятора плохо влияли на работу программы, такие вот факторы. Это встречается крайне редко, не спорю, но я счёл нужным отметить это на всякий случай, так как сейчас существует много экспериментальных и экзотических языков, где такая проблема всё ещё присутствует.
> Быстродействие всегда и зависит от программиста..
Нет, это не так. В интернете есть много сравнительных бенчмарков для популярных языков типа php, js (node), scala, go и так далее. Они все работают по-разному.

Про ассемблер - хорошая шутка с долей шутки. Я не стану на нём писать для веба, потому что количество работы явно не соотносится с результатами (я не очень хорошо его знаю, хоть и учил). Но всё равно спасибо.

Спасибо, но пока не помогло. Deny all я убрал, autoindex off поставил, на файлах всё равно 403. Возможно, из-за прав, но теоретически 0644 позволяет же их читать.