Office 15 embraces ​HTML5/Java​Script ?

a followup to this post and this post, yet more findings in ms job postings.

it looks like Office 15 will leverage HTML5/JavaScript as its new application development platform.

https://careers.microsoft.com/JobDetails.aspx?jid=38841

Did you know that a third of developers have built something on Office? The Office Solutions Framework team is a central driver for Office client & server programmability. Our customers have made significant investments building custom solutions on top of our platform with technologies like VBA, VSTO, Workflow, & Open XML just to name a few. In Office 15 we are focusing on building a modern Application Model centered around web technologies like HTML and Javascript, as we adapt to trends in the industry.

https://careers.microsoft.com/JobDetails.aspx?jid=42957

Now is the time to take Office programmability to the next level. We're a small but strong team within Visual Studio that is currently in the planning stages for Office 15 programmability tools. One of our key goals is to enable professional developers to contribute to the Office platform by making development for Office as easy and fun as building applications for the next version of Windows! Integration of JavaScript/HTML5 will enable developers to create rich applications that span clients and server, integrate with Office 365, enhance the SharePoint experience, and unlock new scenarios that unleash the great potential that lies in the combination of Office and the cloud.

and also, more clues about WinDiv treat HTML5 as a 'native' application development platform for Windows, now WinDiv is building internal code checking tools for JavaScript/HTML5

https://careers.microsoft.com/JobDetails.aspx?jid=28700

The Windows Engineering System and Compatibility team is responsible for advancing many mission-critical analysis infrastructures widely deployed across the company. Our ownership area spans a large spectrum of technologies including PREfix, key PREfast plugins (EspX, EspC, and Goldmine), SAL, Vulcan, and Magellan. Our technologies are now an essential part of the production of most major Microsoft products. We're driving several big initiatives and this opens up many exciting opportunities. We are investing in areas such as finalizing and cleaning up SAL annotations, shipping advanced checkers externally to help the Windows ecosystem, and building new engines to support dynamic languages like JavaScript and HTML5.

now WinDiv and OfficeDiv are both on the HTML5 side,

Is this going to be like when MS first "got the Internet" and spent the next 10 years plugging all the leaks?

23 minutes ago, DCMonkey wrote

Is this going to be like when MS first "got the Internet" and spent the next 10 years plugging all the leaks?

Last time Microsoft embraced and extended the web as strongly as they have been lately we got AJAX, which revolutionized web apps. So I hope we can see similar things from Microsoft in the future.

I do hope they can share the properply working grid control that's absent from HTML5. So far those paid grid controls out there are horrendous and doesn't work properly on every browser.

@magicalclick:

What is wrong with "<table>"?

11 minutes ago, magicalclick wrote

I do hope they can share the properply working grid control that's absent from HTML5. So far those paid grid controls out there are horrendous and doesn't work properly on every browser.

Or we could just keep using VSTO with WinForms or WPF. Maybe some sort of HTML5 based extension platform for Office 365 makes sense, but to use it as yet another development platform for desktop Office development smacks more of the "lets put [new technology] into EVERY MS product no matter its usefulness in that context" wave that rolls through MS every time they create (or jump on the bandwagon of) some new hotness.

That and it sounds like an XSSer's playground, though I assume they'll be smart enough not to embed this stuff in actual document files this time around.

51 minutes ago, Bass wrote

*snip*

Last time Microsoft embraced and extended the web as strongly as they have been lately we got AJAX, which revolutionized web apps. So I hope we can see similar things from Microsoft in the future.

I'm very wary of this. OWA Premium in Exchange 2010 leaves me feeling raw: the AJAX scripts are slow and laggy (but I can't tell if it's due to inefficient scripts or deliberate delays coded into them), I'm also not a fan of the "no well-defined edges" in OWA2010's graphic design. OWA2003 was the best ever, imo.

I don't want this 'inefficient-feeling' ethos to spread to other applications. I like how Google's web applications have that whole 'thin and light' feel to them with virtually zero UI delays. Microsoft's got a fixation for them if you can remember Windows XP's sidebar link lag.

@Bass:

<table> is not grid. Once you want to incorporate various features (including hide/unhide columns), it is very difficult to make it works. If I remember correctly, hiding a column in FF will make the following columns applying wrong widths, which is unwanted. If you want the properly grid resize behavoir, it is hard too as grid column width is both dynamic and static. And to make it worse, column definitions on FF is useless for resizing column. And many more problems with enable/disable column resize per-column. Just try build-one and I will test it out and tell you it works proerply or not.

@DCMonkey:

Yeah, probably just for Office365 and SkyDrive. I just can't picture how it works. Because Office is not even WPF. And doing Native and HTML5 means diverted resources. From a dev perspective, I prefer WPF/SL since code base is more consistant. But, I can see why they want HTML5 for Office365 as well. It is a tough call.

13 minutes ago, magicalclick wrote

@Bass:

<table> is not grid. Once you want to incorporate various features (including hide/unhide columns), it is very difficult to make it works. If I remember correctly, hiding a column in FF will make the following columns applying wrong widths, which is unwanted. If you want the properly grid resize behavoir, it is hard too as grid column width is both dynamic and static. And to make it worse, column definitions on FF is useless for resizing column. And many more problems with enable/disable column resize per-column. Just try build-one and I will test it out and tell you it works proerply or not.

I've never had any difficulties developing usable data-table widgets for the web, just make sure you're using the right scripting libraries. I'm not a fan of ASP.NET AJAX.

20 minutes ago, W3bbo wrote

*snip*

I've never had any difficulties developing usable data-table widgets for the web, just make sure you're using the right scripting libraries. I'm not a fan of ASP.NET AJAX.

Me either, I never used ASP .NET AJAX. Meaning it is difficult, as, it is difficult.

Just upload a grid, and I will tell you it meets my requirement or not. Here are all the typical grid requirements.

1) dynamically resize cols when resize table (since the table will auto resize with browser).

2) manual resize a col will shrink all cols on its right, while cols at its left stay the same.

3) A button to hide/unhide a random column in the table.

4) Grid Header will not disapear when scrolling the table.

5) Some cols can manual resize, some cols cannot manual resize.

6) Some cols does not resize when table resize. Some cols will resize when table resize.

7) Multiple rows for the header. Some header span multiple columns and they support manual resize as in #5.

8) Able to select multiple row using shift-click and ctrl-click (make it simplier, no drag select)

9) Works on all three IE, FF, Chrome.

10) Not slow.

Indeed it is done in <table>, but, very challenging IMO.

So, go ahead and upload it and let me see how easy it is for you.

Yeah, probably just for Office365 and SkyDrive. I just can't picture how it works. Because Office is not even WPF. And doing Native and HTML5 means diverted resources. From a dev perspective, I prefer WPF/SL since code base is more consistant. But, I can see why they want HTML5 for Office365 as well. It is a tough call.

Well, you can supposedly embed a WPF UserControl in a WinForms based VSTO app but that isn't the most graceful thing in the world. Heck you could probably embed a WebBrowser control and get part way to where they are going with this newfangled framework.

As to how this is all going to work, I'm picturing some new "WinJAX" framework at the next PDC with lots of new block diagrams to ooh and ahh over.

Seriously? You guys have no imagination

11 hours ago, PaoloM wrote

Seriously? You guys have no imagination

Who's the 'You' in 'You guys'.  I can, in fact, imagine quite a lot of things...I just choose to keep them to myself.

Seriously, though, it looks like the next 'big thing' is leaning towards JS.  Again.  And because quite a lot of devs don't know how to develop JS apps correctly, we'll end up suffering. 

Case in point:  This stupid C9 edit box chooses to put the submit button in the middle of my text, and sometimes, the expansion of the box occurs but the grey bar at the bottom doesn't realize it, so I'm typing blind.  But, hey, by all means, make sure it's easy for Raymond to post another film festival.

For me as a Word "power-user", this would be an interesting development. 

I am not a professional developer, as my day job is legal; but I have been an amateur programmer for years, creating tools to help with my own legal document processing (e.g. I have re-implemented the insert cross-reference dialogue with much more functionality).

As well as the venerable VBA and UserForms, I have created a number of "HTML/JavaScript apps" to automate word from a web page, using "mshta.exe" and ActiveX objects, which is effectively part way there.

I do not have the time to master the might of Visual Studio, nor do I have the security clearance at work to install any thing like a ".dll" on my system. 

As a result VBA / JavaScript (through mshta.exe) solutions are the ideal solution for me, being quick and fun to develop, and authorised by our IT department (within limits, i.e. no sharing).

If Microsoft were to enable JavaScript as first class alternative macro language (in effect), I would be interested to see how it interacts with the Windows API.  You can go quite far with VBA and the Windows API, so does Microsoft intend to offer the same through JavaScript, and will JavaScript have some new native data types to support this (some of the recent ECMA Script Harmony proposals may help)?  

I would also be interested in how they deal with the problem of supporting multiple computers, where VBA macros are a problem I understand.

Maybe this approach might allow more custom Office development like addins to potentially be deployed to both client and web Office versions starting with Office 15 and a future version of Office Apps (I prefer the term Office Web). Wouldn't a HTM5 based Office allow deployment to non Windows based platforms like Apple and Linux if HTML and JAVA are mainly or only used?

I find it strange that on one hand Microsoft is pushing hard for Windows Everywhere with their port to ARM but on the client side of things they want people to use open standards (HTML5/JS) where the OS is irrelevant. If I were them I'd forego the expense of porting Windows to ARM and stick with WP for devices being that they can run IE9 and render HTML5/JS equally as good as Windows. It just seems like WinDiv has been given free reign to do whatever they want even if it doesn't make sense (and don't take that as if I respect DevDiv either; my avatar speaks for itself there).