Pros / Cons for JavaScript API?

4341
19
01-03-2013 04:15 AM
DanielK
New Contributor
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
0 Kudos
19 Replies
AxelSchaefer
New Contributor II
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.
0 Kudos
DeminHu
New Contributor
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.
0 Kudos
JohnnyPenet
New Contributor
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
0 Kudos
HemingZhu
Occasional Contributor III
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....
0 Kudos
JohnnyPenet
New Contributor
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
0 Kudos
JeffPace
MVP Alum
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.
0 Kudos
AxelSchaefer
New Contributor II
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.
0 Kudos
DeminHu
New Contributor
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.
0 Kudos
JohnnyPenet
New Contributor
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.
0 Kudos
PhilipKnight1
Occasional Contributor
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....
0 Kudos