Задали такой вопрос на собеседовании. Есть идеи как ответить?

  
Варианты ответов:
-- и так ХЗ как на нем писать, а тут еще и многопоточный...
-- в нормальных многопоточных языках есть специальные конструкции для синхронизации потоков. Семафоры там, всякие... В Js этого нет...
-- А он и так многопоточный! Просто многопоточность его однопоточна 
-- Дык, одна JS машинка на броузер. Это еще Великий и Ужасный БиллГейтс со своим Бейсиком завещал...

kronos_vano, 
JS - это клиентский язык. Не имеет никакого смысла его делать многопоточным. 
Потоки юзаются на сервере, а на всех серверных языках (JAVA, C#,...)   есть потоки. 

И вообще,  почему бы не назвать AJAX  - многопоточностью    

kronos_vano, дык он и так быстротой не отличается  ... а thread-ы можно эмулировать всякими setInterval() или setTimeout() 

я бы им встречный задал,  "А что бы вы делали с потоками в javascript?"

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

В данном случае есть несколько вариантов ответа в зависимости от того, что считать сутью явления, расслаивая картину как капустный лист:

1. Потому, что разработчики браузеров и скриптовых машин (Rhino, SpiderMonkey) так создали свои программные продукты.

(На это можно ответить - это итак понятно, мы имели в виду - почему они так их написали?)

2. Потому, что составители спецификации ECMAScript описали этот язык как однопоточный.

(На это можно ответить - это итак понятно, мы имели в виду - почему они так описали этот язык?)

3. Потому, что задачи, для решения которых этот язык позиционировался (придание интерактивности и динамики HTML-страничкам, проверка правильности заполнения форм и простые визуальные эффекты), не сочли достаточно сложными для того, что бы усложнять этот язык многопоточными конструкциями. А в последствии, даже если кто-то и пересмотрел своё решение, эти конструкции не стали вводить по причине желания сохранить обратную совместимость уже написанных сценариев и сложностей эволюционного перехода к ним.

(На это так же можно ответить - это-то итак понятно, мы имели в виду - почему перед JavaScript изначально ставились такие задачи?
Почему многопоточные конструкции усложнили бы язык?
Почему потом, когда (и если?) была осознана необходимость сделать этот язык многопоточным, этот пересмотр оказалось невозможно осуществить, сохранив обратную совместимость с уже написанными сценариями?)

4а. Потому что этот язык изначально был придуман и введён компанией Netscape для браузера Netscape Navigator в эпоху "браузерных войн" в качестве конкурентного преимущества перед компанией Microsoft и на тот момент развитие языка HTML было таковым, что коммерческие интересы Netscape диктовали этой компании постановку именно таких задач перед этим языком. Более сложные задачи перед разработчивами сайтов при том уровне развития интернета просто не стояли и. если бы была введена многопоточность, это выглядело бы излишним утяжелением этого языка.

4б. Потому, что понадобилось бы обеспечивать thread-safe`овость DOM-дерева и большинства объектов объектной модели. Так же необходимо было бы предоставлять возможность синхронизовывать функции и/или блоки, критичные к многотредовому использованию, придумывать или брать из других более сложных языков механизмы разруливания конфликтов за ресурсы и прочее и прочее. Кроме того, введение этого механизма сильно ослабило бы надёжность JS-машин и на порядки усложнило бы их реализацию без какого-либо существенного выигрыша для тех задач, которые традиционно решаются на этом языке.

4в. Хотя бы потому, что многочисленные методы DOM-модели, которые активно использует колоссальное количество сценариев, стали бы работать по-другому, с задержками. Ряд методов наверняка пришлось бы убирать, другие - вводить. Не надо ещё забывать "особую точку зрения на стандарты" компании Microsoft, которая бы наверняка не упустила бы лишнего шанса устроить очередную гадость несчастным скрипт-кодерам, старающимся писать кросс-браузерные скрипты, сделав свою реализацию многопоточности в JScript частично или даже полностью неcовместимой с ECMA. Всё это привело бы к колоссальной путанице.

(И на это можно было бы ответить - это-то понятно, мы имели в виду - почему...? и т.д.)

P.S. Обычно на собеседованиях вопросы задаются не с целью получения правильного ответа. Как видишь, данный вопрос его не имеет по существу. На собеседованиях обычно задают вопросы для того, что бы по твоим ответам что-то про тебя понять, в данном случае - насколько глубоко и многосторонне ты мыслишь.

Конечно, в сказанном есть много нужного и полезного, однако я склюняюсь все же к тому, что однопоточность javascript вытекает из того, код скрипта интепретируется ядром браузера, а не компилируетсяю А исходя из принципа интерпретации кода выполнение последнего в многопотоковом режиме в принципе не только не нужно, но и, насколько я понимаю, невозможно.

Конечно, попадая под влияние предыдущего поста, можно задаться вопросом: а почему обязательно интерпретатор, а не компилятор? - На этот вопрос, думаю, ответить еще проще:
а) компилятор вводит ограничения на код, так как он должен быть в таком случае полностью загружен и обработан и выполнение "на лету" как бы невозможно - противоречие заложенному в браузеры принципу;
б) кроме стандарта на javascript ECMA-262 в этом случае прийдется вводить дополнительные стандарты на компиляторы, и, как следствие, понадобится ввод дополнительных виртуальных машин;
в) аналогично пункту а выполнение скрипта будет сопровождаться задержками, связанными с загрузкой, компиляцией и выполнением скрипта;
г) это превышает потребности браузера, так как поставленные изначально перед скриптом задачи не требуют задействования сложных механизмов подготовки и выполнения кода.

JavaScript сам по себе не является ни однопоточным, ни много поточным.

Все зависит от реализации.

Браузерная реализация JavaScript, действительно, является однопоточной.

Но, например, реализация, на платформе Mozilla Rhino позволяет создавать многопоточность, использую стандартную работу с потоками в JVM.

Вот пример:

А тот же питон вот так вот в наглую этот самый принцип (кстати, в чем он состоит) нарушает? )

Мое мнение в четвертом пункте уже высказал Се ля ви. Просто нецелесообразно в текущих реализациях. 
Кстати, стало интерестно как языки с поддержкой многопоточности и изменения кода на лету разруливают таки ситуации.
Например:
 
Код изменится только для текущего потока или для всех?