3 ms·

One point not in the existing comments is the event driven nature of the browser - even if you're eventually able to have good support for other runtimes in the

One point not in the existing comments is the event driven nature of the browser - even if you're eventually able to have good support for other runtimes in the browser (e.g., you can use Python via the Native Client plugin) most of them have such a large existing codebase of blocking code that I think you'd run into a lot of the same issues that you do now with Ruby & EventMachine, or Python & Twisted. It's what made Javascript such a great fit for nodejs - no big existing libraries of blocking code, and everybody was already accustomed to doing things in an event driven style due to the browser.

dextorious 15y ago
That doesn't make any sense. Javascript libs are just as blocking as any python or ruby lib. "no big existing libraries of blocking code" (for js) just translates to "no big existing libraries", period. It's not like javascript has any special support for non blocking code --or that any code that does anything useful and specific (ie. not just handling out work to be done and callback/returned but actually doing the work) can ever be non blocking.
- mhansen 15y ago
  Javascript has anonymous function closures - nice sugar for a non-blocking API. Python doesn't have them.
tolmasky 15y ago
Nothing in these languages prevents them from being event-based or non-blocking. All these languages have perfectly fine callback architectures. Javascript wasn't magically designed to be event-based, its just that the DOM APIs (which have nothing to do with JavaScript) were written in an event-based way because it really couldn't have been done in any other way. Similarly, if you were to put Python or Ruby in the browser you would necessarily need them to have some sort of DOM APIs (or there wouldn't be very much they could do in the browser). Those DOM APIs would once again be written in an event-based way. The "big existing libraries of blocking code" would be inconsequential since they would for the most part have nothing to do with the kinds of things you are doing on the web. Who cares if theres some file reading code in Ruby that is blocking? You don't read files in browsers. Think of the opposite proposal: if I went and implemented these same libraries in the same blocking fashion in JavaScript, it wouldn't all of a sudden become a worse language for the browser.

dextorious 15y ago

That doesn't make any sense. Javascript libs are just as blocking as any python or ruby lib. "no big existing libraries of blocking code" (for js) just translates to "no big existing libraries", period. It's not like javascript has any special support for non blocking code --or that any code that does anything useful and specific (ie. not just handling out work to be done and callback/returned but actually doing the work) can ever be non blocking.

mhansen 15y ago
Javascript has anonymous function closures - nice sugar for a non-blocking API. Python doesn't have them.

tolmasky 15y ago

Nothing in these languages prevents them from being event-based or non-blocking. All these languages have perfectly fine callback architectures. Javascript wasn't magically designed to be event-based, its just that the DOM APIs (which have nothing to do with JavaScript) were written in an event-based way because it really couldn't have been done in any other way. Similarly, if you were to put Python or Ruby in the browser you would necessarily need them to have some sort of DOM APIs (or there wouldn't be very much they could do in the browser). Those DOM APIs would once again be written in an event-based way. The "big existing libraries of blocking code" would be inconsequential since they would for the most part have nothing to do with the kinds of things you are doing on the web. Who cares if theres some file reading code in Ruby that is blocking? You don't read files in browsers. Think of the opposite proposal: if I went and implemented these same libraries in the same blocking fashion in JavaScript, it wouldn't all of a sudden become a worse language for the browser.