JavaScript API and HTML5

[MichaelDiss-Torrance]

I heard a lot of talk about how HTML5 "may" replace the Silverlight API and/or the Flex API. Beyond that discussion, what does the future hold for HTML5 and the "current" JavaScript API?

I've got a bunch of code written for the JavaScript API (HTML, CSS, Dojo). I'm worndering will I need to rewrite all that in order to interface with HTML5? It may be easier than an application written for Silverlight/Flex, but it's still a rewrite! Am I incorrect on this?

I ask, because I find every couple years I always rewriting the same application (ArcIMS to ADF to JavaScript API to ???).

Mike.

[AxelSchaefer]

I cannot answer the question, because I don't know the concepts of HTML 5 so well.

What do you have in mind? What will be the changes that affects your code? What are the new features of HTML 5 that you can use? Canvas? SVG? Audio/Video? Sections? Geolocation?

The other question: ArcIMS -> ADF -> APIs is a historical thing and has a lot to do with the technical evolution in the last couple of years.

The standard client was framebased HTML, but there was no need to use that. You could have used any JS-API or any Flex impelementation with the ArcIMS backend. You needed the scheme/DTD of the ArcXML and a parser. There were also some JSF clients around for accessing ArcIMS services. So the technology and viewer that were used were mostly and simply the provided sample. It was fast to adjust, easy to use. But it was grey colored and commuicated over the frameset. There was no AJAX in these days and most people didn't want to have a JSF/ASP framework.

The ADF is a great idea of using and modularize client features for the SOAP backend. You have a good control over your code and functions. But you have to learn ASPX and C#/VB.NET (JSF/Java) and to know about the communication with the used AJAX frameworks. It's a complicated thing and nice for programmers. But it is too much for a standard gis-user without so much programming knowledge.

The APIs went another way: They encapsulate the REST statements in their client-frameworks nearly the same way. You can choose which one you like (or even write an own, you only need to follow the REST implementation). The advantage here is that the user can do it without so much knowledge of programming than in the ADF. The communication is part of the framework (JS-API with DOJO over Ajax, Flex and Silverlight in themselves). The REST interface is easier to understand than the SOAP endpoints. It's simply human-readable (although "SOAP is more polite than REST"). The JavaScript API itself can be integrated in some larger environment like .NET or Java.

I think, these changes were driven by the common technlogy of webbrowsers, frameworks and infrastructure. AJAX - for example - makes only sense in environments with a good network. Image blending is only useful when the webbrowser supports transparency algorithms. Floating Panels or adjustable panels were coming with the emerge of JavaScript functionality in the webbrowsers and with the ideas of webdesigners to use them for a better user-experience. The plugin-based frameworks are only useful with a widespread plugin-framework. It has nothing to do with HTML.

What you are worrying about is how the blessing that W3C gives to HTML 5 will change the internet-world and your code. My guess is: not the HTML standard will give you the need to change your code but a new internet-technlogy that will arise in some years: a well-structured, process-related, interdisciplinary, user-friendly meta-language.

🙂

[DavidMaltby]

I cannot answer the question, because I don't know the concepts of HTML 5 so well.

What do you have in mind? What will be the changes that affects your code? What are the new features of HTML 5 that you can use? Canvas? SVG? Audio/Video? Sections? Geolocation?

The other question: ArcIMS -> ADF -> APIs is a historical thing and has a lot to do with the technical evolution in the last couple of years.

The standard client was framebased HTML, but there was no need to use that. You could have used any JS-API or any Flex impelementation with the ArcIMS backend. You needed the scheme/DTD of the ArcXML and a parser. There were also some JSF clients around for accessing ArcIMS services. So the technology and viewer that were used were mostly and simply the provided sample. It was fast to adjust, easy to use. But it was grey colored and commuicated over the frameset. There was no AJAX in these days and most people didn't want to have a JSF/ASP framework.

The ADF is a great idea of using and modularize client features for the SOAP backend. You have a good control over your code and functions. But you have to learn ASPX and C#/VB.NET (JSF/Java) and to know about the communication with the used AJAX frameworks. It's a complicated thing and nice for programmers. But it is too much for a standard gis-user without so much programming knowledge.

The APIs went another way: They encapsulate the REST statements in their client-frameworks nearly the same way. You can choose which one you like (or even write an own, you only need to follow the REST implementation). The advantage here is that the user can do it without so much knowledge of programming than in the ADF. The communication is part of the framework (JS-API with DOJO over Ajax, Flex and Silverlight in themselves). The REST interface is easier to understand than the SOAP endpoints. It's simply human-readable (although "SOAP is more polite than REST"). The JavaScript API itself can be integrated in some larger environment like .NET or Java.

I think, these changes were driven by the common technlogy of webbrowsers, frameworks and infrastructure. AJAX - for example - makes only sense in environments with a good network. Image blending is only useful when the webbrowser supports transparency algorithms. Floating Panels or adjustable panels were coming with the emerge of JavaScript functionality in the webbrowsers and with the ideas of webdesigners to use them for a better user-experience. The plugin-based frameworks are only useful with a widespread plugin-framework. It has nothing to do with HTML.

What you are worrying about is how the blessing that W3C gives to HTML 5 will change the internet-world and your code. My guess is: not the HTML standard will give you the need to change your code but a new internet-technlogy that will arise in some years: a well-structured, process-related, interdisciplinary, user-friendly meta-language.

🙂

You won't see much of a change.  Basically, HTML5 provides for much richer development.  You will still need Dojo and the other APIs.  You probably want to wait to migrate because IE does not support HTML5 yet.  IBM has great tutorials on-line.

[PascalCoulon]

Hi there,

You may be interested by the example of HTML5 and the javascript API: http://www.geo-tag.info/2010/01/07/html-5-geolocation-api/ or this arcticle which will give you an overview of HTML5 and GIS: http://www.geo-tag.info/2010/10/09/750/

Pascal