Mozilla slips SpiderMonkey into Dev Platform of the Future™ Mozilla is building its own version of Node.js – the increasingly popular open source platform for coding server-side applications with JavaScript – moving Node from Google's V8 JavaScript engine to its own SpiderMonkey engine. "We think V8 is great and the fact that Node has become so widely used is a testament to that. But …
Opera need to focus on their core browser a heck of a lot more, and not go running off after random science projects.
with 1% market share and some annoying little bugs hindering adoption and hurting developers (eg for a standards compliant browser they are one of only two - safari is the other - who don't currently support the window.onerror http://jsErrLog.appspot.com ... as there is a fix checked into WebKit it looks like Safari will get it soon)
Event-driven code that doesn't wait on one step's completion before processing another.
I was doing interrupt-driven real-time code in factory-floor applications in the EARLY 1970's and I'm sure it was old hat to the giant telcos long before I took it up. I even used the techniques to make EFFECTIVE user front ends in Visual Basic 1,0 (company's choice, not mine) that never, ever got data inserts AFU with missing fields but were pleasant to use in the process.
What goes around, comes around and there are a very limited number of paradigms in computing/data processing although there are a near-infinite number of ways to implement them (and mostly f**k them up.
A nice (but older) tool for generating event-driven programs is "ibero" from imatix corp.
http://legacy.imatix.com/html/libero/ Heavier duty tools are available as well..
Usual disclaimer about only being a satisfied customer applies.
I'll get my coat, it's still petty cold for us old guys.
be pushed were he should never even have been considered.
Javascript is, in its current state, one of the worst langage to do serious development, no packages or modules , poor typing, no namespaces, no threading support, entire langage constructs you should NOT use (for in ..) and such, it is just a rushed out langage that happened to be the only solution to a non existent problem.
I fully know of all the "function and prototypes" trickery that have been invented to makeshift the missing functionalities, but those ARE hacks. And the fact that everybody has to re-invent them is a sure proof that it should have been in the langage at first.
All those energies should be dedicated to build a decent modern virtual machine allowing us to use ANY langage we want inside the browser, and with decent development tools.
But, hey, it is more man hours trowed at debugging bugs that should never have bee there in the first place or building libraries to do what is standard in pretty much every langage designed in the last 20 years ... more money creating false value, and more time lost, project late and such...
Awesome rationality.
I've just been exploring whether we should move our C++ app to javascript, and I don't buy your argument. You're right about libraries. And I miss static typing available when a parameter can only ever be an int; but that's the paradigm. Namespaces are there via '.' Debugging is no worse than C++. It *is* irritating to have to do overloading by hand, and even more irritating to have to write 'this' everywhere. But set that against all the issues of building a cross platform C++ GUI app, and I know my recommendation.
with the coming revolution all native apps will be swept away leaving all client UI development (and in many cases entire app development) in javascript in the browser sandbox
C++, C# and VB will become the new COBOL and we'll all miss them
Actually, C and C++ might stick around a little longer as someone has to write device drivers ;)
of course the wrinkle here is things like NaCL (Chrome native run-time) that give the sandbox an injection of C++ but it's a browser specific kludge...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
