nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Pros / Cons for JavaScript API?

DanielK

I have searched for some sort of list with pros and cons for JavaScript API against the other API's but haven't found any so can you with experience please help me with this?

What is good with JavaScript API?

What is not so good with JavaScript API?

Is all API's developed at the same time?
Does JavaScript API have the best performance?
Any limits on the JavaScript that other API's doesn't have?

Regards,
Daniel

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

PhilipKnight1

I think people are far too quick to push to the side how much more difficult it is to maintain and debug javascript.

The biggest case made for OOP was that it was easier to program and conceptualize. To me JavaScript is a step backwards in the world of programming. I surely think that JS has it's place to do simple tasks on the client side (why make a call back to the server to simply do 1+1). But, C is an incredibly efficient way of writing your code, but there is a reason people write in C when C++ is a viable option.

I actually think that JavaApplets should be revisited and redone to bring them into the modern world.

I know I'm ranting here, but to me JS, is like writing in (not visual) Basic, just because things run a little bit smoother. But, to be fair, the only thing you are going to hear from a user when something is choppy is that it's choppy, they are totally going to forget that you came 20% under budget than the other guy and you can make enhanced 50% faster.

just my $0.02

[Edit/Update:]
As a firm believer in "If you complain about something, then do something about it", I was compelled to check out some ways to make using JavaScript easier. My current answer is CoffeeScript. I did some quick testing and was able to easily get it working with Visual Studio 2012. It also seems to work with ESRI API and dojo just fine.

Here's what I used:

Web Workbench with VS 2012 (what I currently use as an IDE) to edit my code and install the "compiler"

I then used a Javascript to Coffeescript tool (and vice versa) to compile my already written code into CoffeeScript so I don't have to re-write my JS code.

The VS plugin (Web Workbench)auto-generates a ".js" file. So you will have to set the "src" attribute to the ".js" file it created.

Maybe this is the way of the future, where JS is essentially the "machine code" that other code gets compiled into....

JohnnyPenet

Demin,

I only doing ArcGis the last 4 years, before I meanly developped .NET applications where it is common to use design patterns. This is why when I started the migration of the Web ADF, I first looked at a way to create a layered application. For Silverlight I had the change to start with PRISM 4.0 which does a lot the help creating application which separates the GUI from the business (MVVM). The only negative is that it takes a lot of study to embrase the ideas behind the PRISM library. But once you endorse the patterns, creating tools and command takes little development time. PRISM contains all the modern development patterns like dependency injection, component container. All components are interface driven.
When I decided to the job over in Javascript, I looked how could I have something simular as PRISM for helping doing MVVM. In the Microsoft Develop world, a lot of people use knockoutJS as the library for doing MVVM. In Silverlight my GIS components where all singleton, and DOJO helped me doing the same pattern. In the GIS components I simply copied the interfaces and developped the code, in some case I even copied the C# code and modified it to match the JavaScript API. The major work to be done for the migration was on the GUI side, and this is not the strongest part in Javascript. Dojo components as tab controls and accordion are compatible with knockoutJS. The goal was to have a page that consists of different independ components. Legend, toolbars are all independed components that can be replaced or removed.
The conclusion is that you can use the same patterns found in Silverlight also in Javascript to create very maintainable applications.
It is possible to ban all javascript code out of the HTML pages so that more experienced GUI designers can do the GUI job.

DeminHu

Thanks for all of your replies.

Yes, I need to learn more JavaScript no matter I like or not, just like my switching web adf to silverlight 3 years ago. it might be a bigger struggle from Silverlight to Javascript ( high-level to low-level language).

I am still not much confident that using Javascript for SOE, MVVM applications. But silverlight is not the future for the developers, I hope Microsoft will not disappoint their fans, there may be another improved high-level programming language or technology will be here in the near future.

AxelSchaefer

For intranet applications Silverlight will stay for a long time as you have your desktop configurations in hand. Internet applications however follow the new technologies.

Seems legit. But that doesn't make the conclusion to the "dead" or "alive" status. Although silverlight might not widespread in the internet and Flash mostly (only) for media-streaming and advertising doesn't lead to a strategic drop of the technlogy. But I don't have a crystal ball and cannot foresee it. It depends on your project. Say, you want to plan your app for the next 3 years, I guess Silverlight and Flash might still be a appropriate choice for that timeline.

Why ESRI stopped their Web ADF in the first place?

That I don't know, but it was more complicated to use and needed a higher entry step than any of the discussed web-apis.

JeffPace1

Silverlight is not dead, but it is End of Life. As a developer, same thing to me.

JS API works great in IE7 & 8, IE6 is another story.

JohnnyPenet

I think "Silverlight is Dead" is very misleading. It is a very big topic and there are lots of good articles on Google talking about it so i don't want or am not capable to explain well. I think Javascript and Sliverlight technologies complement each other. I would like to make use of both strength. As a matter of fact, I had developments a silverlight app using Google Map API. The interaction between Javascript and silverlight are so easier....

Demin,

Wat I meant with Silverlight is that no new versions are expected. Microsoft moved the core development team of Silverlight to other projects. So in the future more and more browsers will no longer support plugins like Silverlight. For intranet applications Silverlight will stay for a long time as you have your desktop configurations in hand. Internet applications however follow the new technologies. Example of product decissions is Adobe which no longer releases new version of flash for the mobile devices.
Already Microsoft and Google have requested extension on HTML 5 for a richer multi media platform.
It is also a question how long (years) ESRI will release new Silverlight and Flex versions of their API. Why ESRI stopped their Web ADF in the first place?
Unfortunally software makers not always looks at the installed base, but rather at what will bring the future.

Johnny

HemingZhu

Demin,

I agree about the statement about development resources, however at long term it will not be a discussion of using Silverlight / Flex or Javascript for web based application but rather choose between JavaScript and native applications for mobiles (IOS / Android Win 8?). Silverlight is at a dead end for Microsoft, still they will support it for a long time. Flex has been put in open source, clearly an exit strategy of Adobe. So the days for browser plugins are counted.
Javascript will have more support from Microsoft in Visual Studio 2012, unfortunaly for us ArcGis guys Microsoft choose JQuery as their favorite library. So investments into Javascript will be very important if you need doing web applications.

Johnny

I think "Silverlight is Dead" is very misleading. It is a very big topic and there are lots of good articles on Google talking about it so i don't want or am not capable to explain well. I think Javascript and Sliverlight technologies complement each other. I would like to make use of both strength. As a matter of fact, I had developed a silverlight app using Google Map API. The interaction between Javascript and silverlight are so easier....

JohnnyPenet

I have very similar programming experiences as Heming, I agree with all of his opinions, but I am not so comfortable with Javascript as he does.

It might possible to develop SOE, MVVM applications with Javascript, I looked Johnney's blog, his blog inspired me a lot with Javascript on GIS, but consider the time, team resource, however I don't think I will easily take Javascript as an option for our enterprise applications now, but I will use them for some easy functionlities which could be public.

All ESRI APIs are good, there is no one over another from my opinion, we just need to select the right ones for the specific application requirements.

Demin,

I agree about the statement about development resources, however at long term it will not be a discussion of using Silverlight / Flex or Javascript for web based application but rather choose between JavaScript and native applications for mobiles (IOS / Android Win 8?). Silverlight is at a dead end for Microsoft, still they will support it for a long time. Flex has been put in open source, clearly an exit strategy of Adobe. So the days for browser plugins are counted.
Javascript will have more support from Microsoft in Visual Studio 2012, unfortunaly for us ArcGis guys Microsoft choose JQuery as their favorite library. So investments into Javascript will be very important if you need doing web applications.

Johnny

DeminHu

I have very similar programming experiences as Heming, I agree with all of his opinions, but I am not so comfortable with Javascript as he does.

It might possible to develop SOE, MVVM applications with Javascript, I looked Johnney's blog, his blog inspired me a lot with Javascript on GIS, but consider the time, team resource, however I don't think I will easily take Javascript as an option for our enterprise applications now, but I will use them for some easy functionlities which could be public.

All ESRI APIs are good, there is no one over another from my opinion, we just need to select the right ones for the specific application requirements.

AxelSchaefer

What is good with JavaScript API?

Dojo.

What is not so good with JavaScript API?

Dojo. 😉

The Esri parts of the JS-API are quite easy and quick to learn. At some point you'll get into the Dojo parts of the API for example for the layout or internal memory data storage. This is more complicated but if you handle the first steps and find a way into the external Dojo documentation, Dojo is also a lot of fun and really powerful.

Any limits on the JavaScript that other API's doesn't have?

Internet Explorer 6, 7 and 8.

HemingZhu

Thank you for all replies!

Does anyone have experience from WPF API?

If we let put the obvious thing as development tools at the side, how does JavaScript work compare to WPF?

Regards,
Daniel

Most of my recent GIS works are done using silverlight or WPF(silverlight is sub set of WPF for client-side). But since i have some intense work on JS API, I will give my personal opinions.
1. First of all: I like both of them! Then again because i have many years of both javascript and C#(C++ and Java) programming experience. So script language or OOP isn't really a big issue to me
2. Developing environment, time and performance: I prefer Silverlight/WPF. You have the best development IDE -visual studio with full blown debugger and rich test framework(unit test/UI test) for u to use (again not against Firebug at all). Personally I found lot easier and fast to write silverlight(C#). And last thing compiled code is still faster than the fastest JavaScript.
3. Cross platforms: I give Javascript a little edge not because the siliverlight plug-in but because Javascript can easily run on almost any systems and integrate into other language, let alone the hot mobile trend!!
4. Rich functionality vs Html5/Javascript: Because the Silverlight runtime is a samll version of .Net Framework. It has rich features that have no Html5/Javascript equivalent: deep networking support, file access, out-of browser apps, call windows system component, rich ways to connect back end database.. just name a few. The evolution of Javascript in recent years has added OO P features to it (dojo, jquery etc) but it hasn't reached the level the silverlight has.
5 Open resource vs industry standard. You could argue that Open resource like dojo or jquery is low cost. I personally think it is a double-edge sword. The lack of industry standard has add a lot of complexity to the development process.. Just compare the easiness of searching a dojo class library and a silerlight(.net class library). (html5 isn't quite here yet-let's wait)
6 easyness for the starter: definitely goes to the Javascript. Javascript is a good language for the beginner.

The above is my personal opinions on Javascript VS Silverlight. Not specific on JS API vs Silverlight/WPF API. Like I said I like both of them. ESRI did a fairly good job on developing those APIs.

DeminHu

Hi, Johnny

Thank you so much, your reply and your blog is really very valuable for me !

I am going to spend my weekend on your blog about how you handle SOE and MVVM applications with Javascript APIs.

JohnnyPenet

I just start to learn Javascript API, but I will not change what I am doing for now. I may use Javascript API for very simple applications in my work.

I wonder how people feel about Javascript API for the enterprise applications : service-orienteted, multiple-tire architecture, Model-view-view model design pattern etc. and how people sure html5 is really going to work on all browsers and when it could.

I really like to know GIS developer's experiences on these issues.

I started writing an ArcGis framework in Silverlight for a customer as a replacement of web ADF. I choose using Microsoft PRISM to support the MVVM pattern in writing Gis applications in Silvelright.
Later I used the patterns found in PRISM for converting the framework written in C# into a JavaScript framework for building GIS applications. To support MVVM I used the knockoutJS library which works pretty well with DOJO. A pattern like dependency injection and the use of containers can be more or less implemented using AMD.
I put the whole process of the Silverlight framework and the JavaScript framework on my blog http://jpenet.blogspot.com , it is not perfect and complete put could give you an idea how you can move from the ArcGis web ADF into an own library driven template of GIS applications. It also shows how you can easily integrate other API's as Google to GIS applications.

DanielK

Thank you for all replies!

Does anyone have experience from WPF API?

If we let put the obvious thing as development tools at the side, how does JavaScript work compare to WPF?

Regards,
Daniel

JeffPace1

Our County is still standardized on IE7. Javascript API != HTML5

However, it can leverage it.

We use a single deployment of an enterprise application on Tomcat on an internal webserver. That also runs java servlets and other applications. It connects directly to our SDE.

That application is accessed internally, and through a Web Application Firewall (tomcat running modproxy) for external; public and secure access.

The advantage of this architecture is we have a single app, single development environment, single webserver, etc..
(Downside is single point of failure, but redundancy/HA could be easily achieved if we had hardware funds).

Choosing the Javascript API allowed us to not have to worry about platforms/plugins, etc.. And it integrates into our existing JAVA/Tomcat architecture seamlessly.

Plus, if we ever do go to IE9, all i have to do is change the DOCTYPE. I have in fact already done this using quirks mode in IE7 and it seems to be working great!

Long story short is the Javascript API requires the least setup for the end user. Open browser app works. No plugin download, no patches/security concerns, and free development tools for me. Win Win

DeminHu

I just start to learn Javascript API, but I will not change what I am doing for now. I may use Javascript API for very simple applications in my work.

I wonder how people feel about Javascript API for the enterprise applications : service-orienteted, multiple-tire architecture, Model-view-view model design pattern etc. and how people sure html5 is really going to work on all browsers and when it could.

I really like to know GIS developer's experiences on these issues.

JeffPace1

Fair enough. But in the common "one developer" shop, being able to develop a single platform that works for desktop, web, mobile, etc.. (no app stores, etc..) is a huge advantage.

TracySchloss

I started out as a FLEX developer and I still miss a lot of things about it. Better options for developing the look and feel of the interface probably most of all. I haven't heard anything lately about Silverlight, but it sounds like it's not got a long life to it either. If I was starting from scratch, I would probably pick Javascript just because it's the most likely to be around for the long run. I wouldn't completely discount Flash, though, if you were needing to develop a mobile app, as opposed to a mobile friendly web site. These are written in Adobe Air, which doesn't run in the Flash player.

JeffPace1

Pros:
No PLUGIN required!
way of the web - Flash and Silverlight are dead
great community
robust API
great performance
Dojo over jQuery
Mobile support (flash dead on mobiles)

Cons:
Steeper learning curve due lack of "drag and drop" apps
Dojo over jQuery (pro for me, con for many, but hey, just use both, they work great together)

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.