all JScript docs are suddenly missing

[KedarHMSFT]

All of the docs for JScript objects such as WshShell, WScript, and Scripting.FileSystemObject seem to have been summarily removed. That's bad, because it's very much in use today. The only docs I could find are for Visual Basic, which is useless to me.

[welcome[bot]]

Thank you for creating the issue! One of our team members will get back to you shortly with additional information.

[Bartolomeus-649]

Yes, and the one that can still be found link to the JavaScript reference documentation at Mozilla, like JavaScript would be the same as as server side JScript in Windows (ASP, WScript or CScript)

You do realize that VBScript and JScript is still widely in use in millions of places right? And that it a built in scripting language that is shipped with windows.

Why not just move stuff from wherever it needs to be moved from to it's new place BEFORE you delete the original documentation? The way you do things now break down the entire Microsoft Ecosystem, There are forums and blogs linking to MSDN and Technet documentation, as well as to KB articles, blogs, MSDN Magazine articles and so on, and they now just return 404-responses! As an example, take the https://msdn.microsoft.com/scripting page, it used to host everything remotely related to scripting technologies from Microsoft! It was awesome! You could sit out at a customer with a JScript in notepad at one of their servers and could find everything you needed to get the correct syntax for the FileSystem Scripting object in a few clicks. The same procedure now takes hours, it at all possible. You might wonder what the the hugely important content was that you replaced all this useful stuff with at the /Scripting url? That's where you now host a perfectly useless 404-response.

You do realize, that when you do this you are directly making you, Microsoft less competitive, right? When customers compare the cost of using Microsoft technologies they will now have to add the time it takes looking for documentation, which as it is now, can be a larger cost than the cost for the rest of the project. Also, it is worth knowing and to always remember: When a buggy Windows application created by using technology and frameworks in a way they were never intended to be used, and running under the system account to get the FileSystemWatchers to work in System Volume Information directory, by a crappy developer, spreads viruses and crash computers for customer, it will always be Microsoft that screwed up and Windows that is not safe and which is buggy...because the customer will listen and hear what the crappy developer say. So when you mess up the documentation and change how things have worked for decades for no appearant reason, and make stuff unintuitive and difficult to use you are also creating more "crappy developers".

Remember the value chain?

Microsoft => 
   ^       Development tools, frameworks, technologies and platforms => 
   |             MS Partner(Developers, Developers Developers) => 
   |                  Applications and custom solution based on and using MS tech => 
   ^                      Partners customer  = > Windows, Servers, Services, licenses 
   |                                             ------------------------------------
   |                                                                   |
   - - - <==-  - - <== - - MONEY BACK TO MICROSOFT - <== - - - <== - - - 

Why do you make it more expensive for your partners (and customers) to use Microsoft technology by messing around with the things they need to create solutions based on Microsoft Technology?

How can it be that a a VB 6 developer in 1996 could provide more customer xxx in a day than a whole team today can provide in a week using HTML, JavaScript, CSS, Git, TypeScript, Docker, Azure Storage Accounts, Azure SQL, Azure Application Insights, XUnit, npm, PowerShell, NodeJS, Angular (or some other client side framework), and so on....it will probably take just half the week to get everything setup and configured correctly with source control, build servers, integration tests, Azure accounts and permissions. And then, pretty much no matter what they do, they won't even be able to provide a decent printout.

I'm not saying we should bring VB6 back (many do though), but should we really need a VS solution with multiple projects, hundreds of files, several text-based configuration files you have to edit by hand and so many external dependencies it will be a wonder if it at all work without constant supervisions and modifications, just to to be able to start doing what the customer actually is paying for?

[nschonni]

The docs version of the old MSDN link is probably https://docs.microsoft.com/en-ca/scripting/ (I don't know why it doesn't redirect), and seems points to them in the "References" section on that page.

[Bartolomeus-649]

JavaScript != JScript

[KedarHMSFT]

True, but that link is actually what I needed. At the bottom if you look at the "archive" JScript reference, you can make your way to pages for WScript and FileSystemObject and all the others I was looking for.

The remaining question is why aren't any of these showing up in search engines anymore, only their VBScript counterparts?

[Bartolomeus-649]

I have started using the Wayback Machine and when you enter msdn.microsoft.com/scripting there you'll be able to navigate to the real documentation, and end up here: https://web.archive.org/web/20070210211028/http://msdn2.microsoft.com/en-us/library/ms950396.aspx

It's not all there, but most seam to be rather ok and usable.