if it wasn't enough to have google pushing it's weight around to drive new JS and html specs, now microsoft resurrects from the grave with out-of-IE6-history pearls such as:
"Legacy JSRT APIs ... Edge JSRT APIs"
when IE11 rolls out, lots of devs (obviously not in san francisco bubble) will be churning out sites that require IE11 new APIs to work.
let's just hope they at least bring something useful to justify the shitstorm, like they did with XMLHttpRequest (which does not get even the uppercase consistency right)
All of these apis seem to be exposed only when hosting the Chakra engine. They even call out the fact that it's not for in browser:
> However with JavaScript’s increasing popularity in beyond-the-browser scenarios, developers have been requesting to host the Chakra engine outside the browser to enable JavaScript programmability in their native/managed applications across the client and the server.
If you want to use the API the documentation is not particularly helpful on how to put all the pieces together (though it's not too hard to figure out with some guessing).
I used the Active Scripting interfaces in a Windows product then discovered my mistake a year later when MS refused to release 64-bit versions of the .lib files. I won't make that mistake again, no thanks Microsoft.
I don't really get what the advantage of having the EventLoop running on a Threadpool instead of of a single thread is? At first it sounds like disadvantage because of more context switches.
It might be helpful if you really want to run a lot of Javascript EventLoops - but that's not the node.js programming model.
Like past ventures, this will end up being a poorly documented, and disorganised attempt at building an 'ecosystem'. In the end, it will be the odd couple of die-hard MS fanboys and large corporates co-existing in another one of MicroSoft's weird little ecosystems. And Microsoft support will have long receded into the darkness.
If it sounds like I have a chip on my shoulder it's because I do. I am unfortunately working on a SharePoint 2013 app for my employer. I was excited at first. RESTful APIs and most logic client-side in JS! Maybe Microsoft finally 'gets' it!
Nope.
Their documentation is a disorganised mes; a symptom of a company divided into little fiefdoms thanks to stack-ranking. Their REST API is absurdly complicated for simple CRUD thanks to its implementation of oData (kind of). The fact that microsoft cannot do a spec compliant implementation of a 'protocol' that THEY THEMSELVES INVENTED is a damning indictment of the state of their organisation.
Oh and being forced into the MS developer ecosystem has just been peachy. Intellisense doesn't work properly for JS (let alone angular) and their 'project based' organisation system is confusing as hell. I desperately miss sublime text, but not enough to craft SP app packages by hand every time I want to test and debug.
Did I mention that I (painfully) set up a local SP dev environment? SP Online is limited in many ways. I HAD planned to pay microsoft a lot of money (around $200 a month) for a pre-made Azure VM designed for SharePoint dev, but that VM image is a 'MSDN exclusive'. So.... you don't want my money? Instead of taking my money, you'd rather raise the barrier to SharePoint app development for all the developers who aren't in your special little club? (so, most webdevs, the precise demographic MS is trying to woo with their shiny new app model)
Good luck with building your 'app ecosystem'. Seriously, you're going to need it.
12 comments
[ 3.5 ms ] story [ 49.2 ms ] thread"Legacy JSRT APIs ... Edge JSRT APIs"
when IE11 rolls out, lots of devs (obviously not in san francisco bubble) will be churning out sites that require IE11 new APIs to work.
let's just hope they at least bring something useful to justify the shitstorm, like they did with XMLHttpRequest (which does not get even the uppercase consistency right)
> However with JavaScript’s increasing popularity in beyond-the-browser scenarios, developers have been requesting to host the Chakra engine outside the browser to enable JavaScript programmability in their native/managed applications across the client and the server.
IE11 was already released in 2013.
I found this sample program helpful: https://code.msdn.microsoft.com/JavaScript-Runtime-Hosting-d...
It might be helpful if you really want to run a lot of Javascript EventLoops - but that's not the node.js programming model.
If it sounds like I have a chip on my shoulder it's because I do. I am unfortunately working on a SharePoint 2013 app for my employer. I was excited at first. RESTful APIs and most logic client-side in JS! Maybe Microsoft finally 'gets' it!
Nope.
Their documentation is a disorganised mes; a symptom of a company divided into little fiefdoms thanks to stack-ranking. Their REST API is absurdly complicated for simple CRUD thanks to its implementation of oData (kind of). The fact that microsoft cannot do a spec compliant implementation of a 'protocol' that THEY THEMSELVES INVENTED is a damning indictment of the state of their organisation.
Oh and being forced into the MS developer ecosystem has just been peachy. Intellisense doesn't work properly for JS (let alone angular) and their 'project based' organisation system is confusing as hell. I desperately miss sublime text, but not enough to craft SP app packages by hand every time I want to test and debug.
Did I mention that I (painfully) set up a local SP dev environment? SP Online is limited in many ways. I HAD planned to pay microsoft a lot of money (around $200 a month) for a pre-made Azure VM designed for SharePoint dev, but that VM image is a 'MSDN exclusive'. So.... you don't want my money? Instead of taking my money, you'd rather raise the barrier to SharePoint app development for all the developers who aren't in your special little club? (so, most webdevs, the precise demographic MS is trying to woo with their shiny new app model)
Good luck with building your 'app ecosystem'. Seriously, you're going to need it.
/rant