The expense of a Javascript line of code compared to a Java one
theserverside.com
The expense of a Javascript line of code compared to a Java one
1–9 of 9 posts
Re: The expense of a Javascript line of code compared to a Java one
#2The only problem I see that this guy has is, "I don't know of any good tools for Javascript".
These tools exist. Emacs, Vim, Komodo Edit/IDE, ... Visual Studio might even have support for Javascript at this point.
Re: The expense of a Javascript line of code compared to a Java one
#3tldr; some enterprise Java developer is intimidated by the rising popularity of JavaScript.
Re: The expense of a Javascript line of code compared to a Java one
#4A line of Javascript might be two or three times as expensive as a line of Java... but maybe a line of Javascript can do as much as two or three lines of Java.
Re: The expense of a Javascript line of code compared to a Java one
#5I think the article favors the authors bias, I helped architect and write possible the largest JavaScript code base in production, it was for an IBM project and was well over what the article cites as a large Java app. After writing large Javascript apps for several years, I would say in my experience the difference is negligible on a line of code basis. But what can be accomplished with JavaScript is not.
The reason that developers are abandoning, JSP, ASP, PHP for JavaScript apps is because the benefits far outweigh the drawbacks and those benefits would still exist even if JavaScript was double the cost per line (which is the worst way to measure the cost of development).
JavaScript allows us to reduce the technology stack from a bunch of proprietary server languages that are not portable among server, to the browser which is very portable. When a JavaScript front end is designed to communicate with a REST facade, it makes the front end portable among any of the back end choices, further it provides a way to allow a front end to utilize completely disparaenent back ends (think Facebook and twitter integration).
JavaScript forces you to look at your business as a set of services forcing you to develop a service based platform. The advantages of this are becoming more and more apparent.
Finally, in forcing the service based architecture it becomes easy for companies to rapidly produce front ends for platforms like the iPhone or IVR. Delivering to new platforms becomes a rapid development exercise because JavaScript web apps inherently force you to decouple the UI from the business systems.
There are a lot of advantages to developing applications with JavaScript few of them have to do with the cost of line by line code and more to do with total cost of ownership and technical debt. When those are factored in the value of JavaScript apps becomes apparent.
Re: The expense of a Javascript line of code compared to a Java one
#6I think the article favors the authors bias, I helped architect and write possible the largest JavaScript code base in production, it was for an IBM project and was well over what the article cites as a large Java app. After writing large Javascript apps for several years, I would say in my experience the difference is negligible on a line of code basis. But what can be accomplished with JavaScript is not. The reason…
Yes of course you cannot accomplish exactly the same things with Javascript as with Java for the simple fact that Javascript is imposed as (almost) the only scripting language understood by the browser. To use Java on the client side (not as an applet) you need a generator like GWT or our own Strongly-typed Javascript (http://st-js.sourceforge.net ). I agree that the line of code is maybe not the best way to measure the cost of development but it's a simple way to compare similar languages (given that all the other costs of the project are the same regardless the language). Using multiple complex external and internal libraries, refactoring the code to adapt to new business requirements, debugging in Javascript seems very time consuming to me. The help of an IDE these days is extremely important. A simple syntax highlighter (even with some auto-complete support) is far from being enough. I'm still curious what IDE you used for your project and what was the cost, the size of a module where the requirements didn't change much. As a side question, how do you rename a method for example with the tool use (imagine that another method with the same name exists in a different class/module)?
Re: The expense of a Javascript line of code compared to a Java one
#7I think the article favors the authors bias, I helped architect and write possible the largest JavaScript code base in production, it was for an IBM project and was well over what the article cites as a large Java app. After writing large Javascript apps for several years, I would say in my experience the difference is negligible on a line of code basis. But what can be accomplished with JavaScript is not. The reason…
Yes of course you cannot accomplish exactly the same things with Javascript as with Java for the simple fact that Javascript is imposed as (almost) the only scripting language understood by the browser. To use Java on the client side (not as an applet) you need a generator like GWT or our own Strongly-typed Javascript ( http://st-js.sourceforge.net ). I agree that the line of code is maybe not the best way to measure…
I'm still curious what IDE you used for your project
I use Netbeans, it does not get a lot of press but they have been outpacing many of the dedicated JavaScript IDE's they have great JavaScript support.
how do you rename a method for example with the tool use (imagine that another method with the same name exists in a different class/module)
I use Dojo for large JavaScript projects, there really is not an alternative when you get the the application sizes I deal in, as such everything is namespaced. Netbeans can refactor methods in JavaScript, so I use the built in functionality of the IDE to do so.
Re: The expense of a Javascript line of code compared to a Java one
#8Earlier quoted context omitted.
Yes of course you cannot accomplish exactly the same things with Javascript as with Java for the simple fact that Javascript is imposed as (almost) the only scripting language understood by the browser. To use Java on the client side (not as an applet) you need a generator like GWT or our own Strongly-typed Javascript ( http://st-js.sourceforge.net ). I agree that the line of code is maybe not the best way to measure…
I'm still curious what IDE you used for your project I use Netbeans, it does not get a lot of press but they have been outpacing many of the dedicated JavaScript IDE's they have great JavaScript support. how do you rename a method for example with the tool use (imagine that another method with the same name exists in a different class/module) I use Dojo for large JavaScript projects, there really is not an alternativ…
I have a colleague who uses Netbeans for Javascript so I took a look. And yes it looks better than the default Eclipse editor for Javascript (the jQuery auto-completion is quite interesting). But still it's not working in many situations, unlike the Java support that works all the time.
Re: The expense of a Javascript line of code compared to a Java one
#9Earlier quoted context omitted.
I'm still curious what IDE you used for your project I use Netbeans, it does not get a lot of press but they have been outpacing many of the dedicated JavaScript IDE's they have great JavaScript support. how do you rename a method for example with the tool use (imagine that another method with the same name exists in a different class/module) I use Dojo for large JavaScript projects, there really is not an alternativ…
I have a colleague who uses Netbeans for Javascript so I took a look. And yes it looks better than the default Eclipse editor for Javascript (the jQuery auto-completion is quite interesting). But still it's not working in many situations, unlike the Java support that works all the time.
Did you add jQuery support through the libraries? or did you just add it in your project, I have found auto-complete works a lot better when you explicitly add the project to Netbeans via the libraries mechanism.