Comment Re:Need a better client-side scripting language (Score 1) 141
Why, oh why did javascript become the defacto client-side scripting language for the browser
If you want to scale horizontally across multi-cores, you need a language that allows easy multi-threading and concurrency
About the only thing JS offers for concurrency is that horrid settimeout function
What we need is a better scripting language
Why not incorporate a Python interpreter into browsers, and develop a stripped down sub-set of python for use on the web
I see no technical issues in doing this, only trying to battle the inertia of JS
I want to correct you on two confusions. First, while setTimeout relies on a timer, but once the event occurs, the user handler is executed synchronously within the primary thread, and its semantics don't allow for parallel execution without serious side effects. You can use setTimeout to simulate cooperative tasking, but not for implementing actual multi-core concurrency.
And second: Web Workers is gradually being adopted by browsers, which is the tool for implementing concurrency: a safe alternative to raw threading. This is a threaded and simplified implementation of the Actor pattern, a background thread that you feed some input, and it's executed isolated in parallel and then returns results in an event back to your primary thread.
Don't confuse a language with the browser API, and don't assume languages and APIs are frozen in time. Other things coming to JS/HTML these days are audio processing, video playback and even OpenGL (WebGL), as you may know, so I'd say JS is keeping up with the times adequately.