Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Now that frameworks like GWT, Morfik etc exist which compile Java client side code into major JavaScript dialects, is it still worth learning JavaScript?
In my book, yes.
I'm a strong believer in understanding the underlying technology beneath whatever toolkits you're using.
Abstractions are leaky - you'll run into trouble down the line if you try to get away with only understanding a high-level toolkit, and not the underlying technology. Sooner or later you'll need to debug your project at the JavaScript (or whatever) level.
Understanding the technology behind your framework reduces the time spending on debugging the things you do with your framework. so in my opinion it's always good to know whats going on behind the scene.
Yes,
...and I speak with experience: I've never learned javascript and only used parts of it, when I encountered it in google searches for questions.
Now that I'm building a Web application, I notice that not all abstractions away from javascript have the desired functionality, and I need to go into javascript to solve it.
I notice that I miss the fundamental knowledge I have with other languages, just like I miss the 'javascript programming language' book (I'm not sure it exists but I have similar copies for C, C++ and Java). So today I ordered Javascript:The good parts and I will learn it...
ABSOLUTELY. In my opinion, abstraction is important, but knowing how that abstraction works is equally as important.
I've seen developers who live and die by their frameworks (javascript: jquery, yui, etc... or php: zend, cake, etc...), but have no clue how to do anything productive without them.
Who would you rather be (or hire)? The guy who knows how everything works, but improves his productivity by using frameworks and libraries... or the guy who uses these resources with no idea how they actually work?
Stretching this further...
Should you learn assembly language nowaday with so many higher level languages?
Should you learn how to do basic arithmetic like subtraction and addition by hand when now we have calculator and computer that can do this for you?
Well, I'd say maybe you won't need to if you don't have any reason to go deep down, but someone will have to still.
As with all things, there is a balance. Know that it will be to your disadvantage if you don't know the lower level stuffs, but sometimes it is necessary to skip it so you can be deep in something else. You have to admit there are so much technology out there that you won't be able to be an expert in all things. In that case, knowing someone else who does is a good thing.
So pick your choice and go with what interest you. If you think you are interested in learning JavaScript go for it. If not, you can stick to your level of abstraction and get a JavaScript buddy that can help you when you are stuck.
I think the reality of browser bugs will make being able to diagnose and understand the generated JavaScript necessary for a long time. I worked with a Spreadsheet company for OS/2, and they had to read the generated assembler from the C++ code because the IBM compiler would generate buggy machine code at times. So while they may not have known enough Assembler to write a whole project in it, they certainly had to know enough to track down problems.
That being said, there are also many web frameworks that require you to code your own javascript, and a given toolkit won't necessarily do everything that you need to do without directly writing some javascript. You can choose frameworks that avoid it if you prefer, but it isn't at all obvious that, unlike say Assembler for application development, the Web development community has decided to abstract away any involvement with it. You may well end up on projects that need it.
Actually, drawing a parallel to assembly language is a bit missing the point. Assembly was platform specific and the move to C enabled a certain level of platform agnosticism, allowing the developer to be more productive on multiple platforms. Hence, there was a real productivity effect.
Learning all your rich web chops on something like GWT is more limiting. It is, after all, based on Java, and the web is way larger in scope than just Java. You'd be seriously limiting yourself if all you know is GWT but not the inner workings of the generated Javascript (Can't comment on Morfik as I don't know it).
However, employing something like JQuery in order to be more productive when coding Javascript is much better. JQuery can be used on any browser running on any OS, so it doesn't limit you.
I'd say yes. I've met people who claimed to know javascript, when all they could do is do a couple of jquery function calls. Javascript (ECMAscript) is a beatiful little (ok, not so little) language.
Abstracting a bit from javascript - define "worth learning". This kind of thinking was always a conundrum to me. Are you, per chance, afraid of learning something new?
I guess, this kind of thinking is what really separates a coder from a programmer.
A web developer who does not know Javascript is like an auto mechanic who does not know how to change a tire.
JavaScript is the core of interactive client-side development. It is absolutely essential. After you know JavaScript you might decide to try out other things that compile to JavaScript if you find them easier.
Also if you want to work professional in web development for some company then you are going to have to know JavaScript. Besides, JavaScript is getting more and more popular as the execution of the language in the browser gets faster and as it becomes more popular in Server-side development as well.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We're developing a system which can be best described as a layer above social networking. It's extremely data heavy, would involve a huge user base, data base would be beefy basically, but it wouldn't involve complex computations. The most complexity would involve fast retrieval of data. Now, we have programmers who're comfortable with JAVA as well as PHP. The front end is nailed - Javascript, HTML, CSS. But we're having a huge debate on what to go with for the back end. We consulted numerous blogs and forums and have a consensus on the pluses and minuses. To sum it up, people say that it's a pain to host Java but it's extremely scalable, whereas PHP is fast and easy to host, but not entirely OO or sturdy. We're still not able to reach a decision. For a system like ours, does it even matter what we go with? Because at the end, it's the performance boosters that matter.... or am I entirely wrong in thinking that? Any input will be appreciated. Thanks in advance!
Java and PHP are both valid choices for developing a web backend. Personally I would choose Java (I'm an OO guy), but the decision for you should be more about what your developers are more comfortable with.
Forcing developers to adapt to a technology which they are resisting will cause problems for management and is likely to even upset the outcome of the project. I would not invest in a project knowing that the developers were not happy with the technology being used - it is too much of a risk.
I would prefer PHP because of the amount of help you can get (if you are ever stuck). It is also very adaptable, and has many CMS systems available.
I agree that for a system like yours, the language does not even matter. Retrieving the data efficiently is what matters, and there are umpteen solutions to help you with that.
So then you should choose the language your team is most comfortable with, and helps you code in a safe way (read: tdd).
For me, from the choice you give me, that would be java, as i don't know any tdd solutions for php (doesn't mean they are not there).
I would be so bold as to suggest an alternative: use ruby and Ruby on Rails. At least, that is the switch I made, and i have never been happier. But that is personal, and you and your team should be willing to learn a new platform (and i can imagine it would defeat the whole purpose).
To rephrase: according to what you told us, the language does not matter. Choose the language and toolset where your team is most comfortable with.
If it's huge data base plus massive read-write in real-time much like apps layered on Twitter feeds and Facebook, you are probably going to be more worried about how fast and efficiently you can retrieve data from database. There are tools to do so, in both, Java and PHP, so you are not going to be worried much what you start with.
I would suggest to with one you have more suitable tools and APIs to develop on. So, to answer your questions:
For a system like ours, does it even matter what we go with?
It does not matter what you choose. At least, when starting it is premature to decide what's the best. I've seen pretty efficient system on Java. So, I am inclined towards Java.
Because at the end, it's the performance boosters that matter.... or am I entirely wrong in thinking that?
Performance boost will come with faster data-retrieval and ability to handle large request load. Java scales pretty well. But there are high performance sites build on PHP.
I would say, it's a good idea to evaluate what makes you to do less work in getting your app done and go with that. In massive load situations, you might have to tweak things in either of the cases.
You should design your system to scale well with the number of users. You will find CPU/memory is relatively cheap these days so using a bit more cpu/memory is not as big a problem as it used to me.
I would say if you can use Java or PHP, you should consider using Java AND PHP. This way you can take advantage of the best of both languages.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I studied 2 courses in Java:
1- Introduction to programming with Java.
2- Data structures with Java.
In Both courses we used Java SE.
I loved it and I really want to be a great java programmer.
But, I discovered that I should know many technologies involved in Java software development:
Spring, Struts, JSP, JSF, GWT, Hibernate, apache tomcat and many more actually a lot more.
I hope it become simple process like .NET
you choose one language with one framework and IDE that is it.
Could anyone guide me to the best route or path to master Java, please?
What do you think about these two courses:
http://www.oreillyschool.com/certificates/java-programming.php
and
Advanced Java Certificate Series (from the same school, will be available in September).
I think most programmers have about average college graduate intelligence, including myself. What we do have a lot of though is patience.
That said, there are efficient ways to learn and inefficient ways to learn.
If you're stuck on one tutorial/book, try another book. Once you're done with the basics, there really is no "correct" order to learn.
Skim through the standard Java library documentation. Don't bother memorizing it, but be sure that you know the tools are there when you need them.
Make lots of test programs. If you're ever curious about something, try it out and see what happens. Don't know how big an int is? Write a program that prints out a sizeof. Don't know what happens when you call a virtual function of an override instance? Write a program with two classes, one inheriting the other, and try it out.
Read other people's code. Take note of style and structure. And I don't mean silly things like whether the { should go on the same line as the statement, but how they recycle variables, how they organize their classes, how they use loops, where they bother to optimize and where they don't etc. Emulate what you like.
Practice building "stub" programs -- you can do this in your head once you get the hang of it. Find your favorite program, and write out all the classes/methods as you think would have been used to build it. That'll help you with architecture.
Spend lots of time naming your classes. Don't use fancy names, just descriptive ones. It's a good mental exercise to think about names, even if you don't expect to ever share your code.
Try Project Euler if you're into that sort of nitty-gritty mathy stuff. I don't believe that programming is all about math, but you might like it.
Learn C sometime. C++ probably isn't worth it if you're doing java, but C will teach you how your computer works. You don't need to master it, but at least get to the point where you understand memory management and pointers. That'll help you make decisions faster when you want your code to be really fast.
Learn functional programming someday. Haskell's a good choice, because it's a pure functional language. It's extremely difficult at first, but the concepts you learn from it are valuable regardless of what language you program in. You'll be making design decisions a lot faster, and your code will be a lot more robust.
Keep up to date. Trends come and go in this industry as fast as in the fashion industry. A lot of it is crap, but a lot of it is crucial both to employment and productivity. Always keep an eye out, or you'll go the way of the dinosaurs.
The best way to become good at something? Practice, practice, practice.
Don't focus on a single framework just do lots of Java, take a look around open-source projects, find something that needs fixing or implementing and do it or think of something that you want but doesn't exist and make it.
Practice doesn't make perfect - perfect practice makes perfect. If you continue to make the same mistakes, you'll only succeed in developing bad habits.
You need to read this.
Your Java roadmap ought to look like this:
Concentrate on core Java JDK classes to start. Don't worry about Java EE until you're comfortable with interfaces, classes, and the basics. JDBC is an important part of core Java, so be fluent with it. You'll have to know about relational databases, normalization, and SQL. GUI technology here is Swing.
Once you have that, take up servlets, JSPs written using JSTL exclusively (no scriptlets), and JDBC. You'll have to understand something about Tomcat (or another servlet/JSP engine), HTTP, HTML, CSS, and a little JavaScript as well. You can go a very long way with just these.
Once you've mastered 1 and 2, you'll have to make a choice of framework. I'd recommend either swallowing Spring or EJB 3 whole. I'd recommend Spring first, but I'll admit that I don't know EJB 3 well.
I get the impression from the phrasing of your question that Java is your first programming language. I laud your desire to "master Java", but if I might, I'd like to suggest that you try a little breadth before you get too much depth!
It's easy, I think, with a CS degree where most courses are taught in Java, to fall into the trap of believing that all programming languages are:
object-oriented (and with single implementation inheritance and multiple interface inheritance)
statically-typed (with no type-inference)
imperative (i.e. making use of iteration constructs and mutable state)
verbose
and therefore that all programming must look roughly like Java programming.
I'd humbly suggest doing some reading on different paradigms and languages: learn a dynamically typed language (coming from Java, I'd suggest Python or Ruby), learn a non-OO language (like C)---and implement OO, learn about functional programming (Haskell's a great eye-opener). At least take a look around before diving head-first into Java alphabet soup (Java culture highly values acronyms---but I'll pass no value judgments on this here).
Just my US $0.02!
Write programs in it. Find open source programs that use it and fix their bugs and add functionality to them. The best way to get experience is to experience it.
If you really want to know what you should be studying, within the realm of your examples (Spring, Struts, JSP, JSF, GWT, Hibernate, apache tomcat), then find some podcasts and blog posts that allow you to survey these technologies. You can then choose the ones you are most interested in for further study.
I agree with the other two respondents (practice, particularly with open-source projects, is the best way to get good at a language). However, I wanted to add one thing. It's unclear from your answer how much experience you have with object-oriented design, and with Java, that's essential. I'd recommend looking into advanced OO design to get a sense for what's out there. My favorite book on OO design is available for free and linked below - see if it's at your level. If not, find something more/less advanced and work from it.
http://homepage.mac.com/s_lott/books/oodesign/build-java/html/index.html
Java Technologies are very vast, from mobile phones, to enterprise level servers. You might want to first narrow what you want to learn.
Your first talk about Java SE(applications programming) and then start mixing in Java J2EE, and Java EJB.
If you want to go down the web route or enterprise server then you need to learn J2EE,EJB,Hibernate,Spring,etc otherwise these technologies aren't seen as often when programming applications.
It still seems like you have a long road to go, probably the most beneficial for you to learn next would be Java Swing(gui).
Practice and learn frameworks as you need them (or come across them). There are way too many frameworks out there (for Java and for .NET) to learn in one shot.
Learning the standard Java class libraries is always a start
The best way to become good at something? Get a job that allows you to use that technology. Get paid while practicing.
There is a time to stop reading books and articles, and get to work building a project.
As you are working, learn from others who are better than you. Continue to read articles on topics that interest you, and apply what you learn at work.
Find a mentor and pick his/her brains often. Once you are working in the field ask for code reviews from senior developers. This will get you out of your own habits, and reading people's suggestions for how you can improve will give you plenty of insights. Don't sit around reading, solve problems on a per-problem basis and work your way up from there.
Its not that easy to became a master in Java, what i have done to study java is
1)try to convert all the apps i have seen into java,
eg:paint to java
2)used to went to JAVA user groups and conference in my state
3)Went to Groups in Goolge for checking Codes of Java
thats all i do, i cant say i am the master, but i am able to do the stuff
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been doing web application development for the last 3 years in PHP. I'm now on the verge to give Java a go. My last use of the language was nearly 8 years ago and was mostly academic.
I'm reasonably well acquainted with PHP's object model (version 5) and I have almost exclusively been coding in OO. I would now like to transport that experience and use it to develop in Java.
Where I'm coming from:
linux as a desktop and server
Vim/gVim + plugins as an editor
MySql for db
apache httpd
experience with a bunch of PHP frameworks, Zend+Doctrine being the ones I use most
What I've garnered so far about a move to Java:
I need an IDE: IntellijIDEA, NetBeans or Eclipse
I need to pick a development framework. Some recurrent names: Spring MVC, stripes, wicket.
Now I need some insight that could help make this transition smoother. But from the way people talk about it, Java seems to be an entirely new beast with its own ecosystem. It sounds as though moving to Ruby or Python would actually be easier, which is curious since, when I look at it, Java conceptually seems the closest to PHP, albeit stricter and precompiled.
As weird as this may sound, very few people have publicly documented their experience of such moves. I have searched google, amazon and stackoverflow for similar questions and the results leave to desire. I just can't believe that I would need to start the same as a newbie if I wanted to be productive as a web developer in Java fast.
Anybody is welcome to respond, but I somewhat think that people with some valuable experience in both languages would enrich this discussion the most.
What helped you get going quickly in Java?
What concepts are omnipresent in Java and absent from PHP and vice versa?
Some gotchas for PHP developers going Java.
How long before you felt the transition was complete?
I wouldn't try to learn an IDE at the same time as learning a language. An easier transition would be to stick to your shell and habitual text editor, and use the following shell-friendly tools:
ant, for organising your project, running automated test suites, incremental compiles
BeanShell for interactive testing, trying things out quickly
A quick trick: javap from the commandline will give method signatures for any class in the standard library. Similar to php -r but gives more information since Java is typed.
The online documentation for Java is precise, professional, and consistent in tone and format. Unlike in PHP where all of the functions are in one flat namespace, the standard libraries in Java are class hierarchies. You've got to know your way around that standard library, which means knowing hierarchies + responsibilities: for example you've got to know that java.util.List is a subinterface of java.util.Collection with the addition of a concept of ordered entries. With that information in your head, a google search for java.util.List will take you to the Javadoc for the class, and the Javadoc will tell you exact method signatures and link you to a selection of concrete implementations.
Some miscellaneous distinctions:
Strings are sequences of characters rather than sequences of bytes. Absolutely the right way of doing it.
Systems produce and consume streams (of bytes or characters) rather than byte buffers. For example, if you wanted to filter the output in PHP, a standard practice is to ask ob_get_contents for a byte buffer then to transform the whole buffer. In Java, you add a filter to your servlet that transforms the output a byte or a character at a time. It's a bit imposing to work with initially but it's simpler and more Lego-like when you get used to it - your stream processor doesn't have to know where things come from and where they go.
Almost everything useful is an interface, and creating an instance of an interface can be tricky, non-standardised, and not always well-documented. In PHP, you can get up and running with XML with new DOMDocument(). In Java, org.w3c.dom.Document is an interface, so new() won't work. Javadoc is very precise about how interface instances behave once they come into existence, but it can be quite coy and prudish when you're trying to find out how an object is actually born. Very often, you'll have to look for tutorials and code examples and copy-paste a piece of boilerplate that gives you an instance of DOMDocument or java.sql.Connection or whatever. One reason frameworks like Spring are popular is that they separate out the ugly object-creation code and present you with a world where interface implementations are just magically there.
I actually switched in the opposite direction. I found that Java works very well in a large company where you might be working on a single component, handing it off to someone else who integrates that component into a larger system, which is then packaged and handed off to a separate operations team - that's where all this indirection and configurability (FactoryBuilderFactory type abstractions, web.xml files, etc) makes sense and does something useful. In a small company where the programmers are the ops personnel, Java is a lot more work. With Java, you'll have to get used to concepts like starting up the Java process, monitoring the Java process to make sure it stays up, monitoring the Java process to make sure that it doesn't go into a coma where it's alive but not responding, shutting down and restarting the Java process with minimal disruption when you're updating code, etc, etc. If you have separate ops personnel, that's fine, it's their job, they're very good at it. If you're a programmer, babysitting a Java process can be distracting and difficult to do well.
Start with the Java Tutorial
http://java.sun.com/docs/books/tutorial/getStarted/index.html
Then go buy Head First Java
http://oreilly.com/catalog/9780596004651
It will get you going pretty quickly in the language which is essential regardless of what you want to do.
Strictly speaking, you don't need an IDE to work in Java. I've been coding heavily in Java for well over a decade (and heavily on other stuff for over 25 years), and I don't much like IDEs. Perhaps that implicit indicator of my age is part of the issue :-) It's a trade-off, like anything else.
I'll plug Stripes as a nice simple framework, but mostly that's because it's relatively small and limited in scope. The large frameworks like Spring are "kitchen sink" ecosystems, and learning Java with one of those frameworks may smooth some of the difficult parts but leave other basic aspects mysterious. Again, it's a matter of personal preference.
It's good to have somebody around who knows the language. Oh, and to that point, make a friend of the Java API documentation. As platforms go, the Java API has its ups and downs but for the most part the documentation is at least pretty thorough and pretty accurate.
You'll also want to get really familiar with JSP and its relationship to Java and Java web service architectures, because that'll be what you'll relate to your PHP experience most directly (I'd think).
The best move I made was from Java to PHP.
Beware of complexity. Primarily, the key to great software is simplicity, and that is why PHP combined with a good framework kills Java.
With Java, you risk becoming a slave to your servlet container and framework. Choose the simplest most flexible framework. Controls and custom tags are the devil. You'll waste days learning things that were designed to make development quicker, but are ultimately too complex and inflexible. Java will slow development due to: complexity, compilation, and static types. You'll come to loathe null pointer exceptions.
Edit: Tools aside, Java and PHP are very similarly structured "C" style languages. Much more so than Python or Ruby. It is the static typing and complex tools that make Java so foreign.
I recommend hitting up JavaBat at here
It will give you some good ideas. It took me 1 solid year in a professional setting to get a very firm grasp on Java and I have been able to move into other OO languages quite easily once I had the thoughts beaten into me.
This appears to be a bit of an old post, but hey...
I moved from C# to Java and I've just started a role and am moving from Java to PHP...
First off: Java is awesome :)
for your IDE get Eclipse, once you get used to it, you never have to leave the IDE (apart from SQL bits). It manages projects really well, you can download alsorts of plugins, such as SVN plugins. It allows you to run a Tomcat server within Eclipse and it will output errors straight to the Eclipse console.
for the framework, I used Struts and Tiles and Torque for the ORM, took me a while to get my head around them, but once we made friends, I can't imagine any other way of developing. Although I imagine for a small project it would be a lot of overhead!
agreed with an above post - get HEADFIRST JAVA, thats how I learnt and I used it for lots of other languages, they have a visual method of learning thats alot easier than pure textbooks - well for me anyway. I was up and running with in a day and confident within a couple of weeks I guess - but always learning :)
yip Java is strict, but you come to love it, for me moving to loose 'ol PHP is a bit wierd.
you will also need to download Tomcat to run your Java bits, its easy as to get running.
Java organises all your classes very nicely, none of this 'require_once(some_text_file.php)' rubbish, just 'import myClass' and off you go.
one of the things that annoys me is, there is no way of telling which JAR libraries you are NOT using, so after a couple of years working on a site, your lib folder can get a bit messy - specially if mulitple people are removing and adding functionality.
I could go on.
Paul
For my case, I only dealt with lot of procedural coding on the php, so jumping to Java, not only did I find everything to be more verbose and less forgiving than php (but now I know why it must be this way, and I love Java a lot) but learning to organizing my code in classes and also learning the eclipse IDE took about 1.5 years of just tinkering, trial & error, making stuff on my own (mainly swing applications).
I guess just creating stuff on your own, utilizing the vast amount of Java libraries out there to build your own stuff is fun is the fastest way. Also I think I could've saved more time by reading the java sun tutorials thoroughly. Even more time saving is making sure you've done a thorough search for libraries that prevent "reinventing the wheel".
Good luck!
I code primarily in javascript and in vb.net. I've found that if I can achieve the same thing in both javascript and vb.net that I feel far more productive and expressive using javascript for the task. I often find myself researching server-side javascript implementations to see if anything has gone mainstream so that I can code my back-end business logic and data access in javascript. Given all the advanced tooling and language features in .Net this preference seems somewhat paradoxical to me. I'm not suggesting one is better than the other (I've been a vb programmer since I started programming), I'm just wondering if my preference is entirely subjective or if anyone else shares it. So, does anyone else enjoy coding in javascript to the point where you prefer it to the .Net and Java environment, and if, so why?
Personally, I'm much more "productive" in .NET than in JavaScript, simply because the framework is more rich and there is much built-in functionality. I also have not started writing code using TDD in JavaScript, perhaps because of the lack of readily available tooling in Visual Studio. For C# and VB in Visual Studio, there are many different ways to achieve very productive TDD. As far as the languages are concerned, I'd say that JavaScript could potentially be "quicker" to hack something together in since it is dynamic - which can lead to more terse code, LOC-wise. Note: "quick" and "productive" are of course different measurements.
javascript just has a higher signal-to-noise ratio, since it doesn't require all that superstructure of declarations and explicit typecasting. If you are confident of your coding, it's much faster to write and debug.
With static-type languages I spend more time thinking about language requirements than problem-solving requirements.
If you want a direct comparison, try ActionScript. It's literally javascript with all rigging added - they hoped it would be the next standard version but failed. It's kind of a litmus test - some people prefer it because of the explicit typing and error-checking. You and I would not so much because of the overhead.
When developing a reasonably large application, I feel more productive in java/c# due to static typing and a larger and more mature set of libraries and tools.
This question is highly subjective though, different people are going to have different experiences and opinions. If you have a choice, you should be doing what works the best for yourself.
I think that if the application required much about correctness and good structure. It should be a server side language. You can achieve things with Javascript but I guess that it's not very complex.
I feel much less productive programming in Javascript than Java. The main reason is that there are so many more portability issues with Javascript implementations; e.g. between different browsers. Other issues include those mentioned by others:
Java has better tools support, both for coding and for debugging across multiple deployment platforms.
Java has far more extensive libraries, both standard and as 3rd-party extensions.
Doing multi-threaded stuff in classic Javascript is sooo convoluted.
Java's primarily static type system (in my experience) makes it better for programming in the large.
However, there are still situations where Javascript is a better solution than Java or C#, despite the productivity issues above, and any prejudices one might have against Java.
node.js is currently the hot serverside JavaScript solution. It would be a big departure from .NET, but its gaining traction.
I think JavaScript as a language offers a very similar set of tradeoffs as other dynamic programming languages. It has some really excellent capabilities to do a lot with less code, but it doesn't have the same safety features or speed.
For the most part, I find that I can get more done faster with JavaScript than Java for example, but it can sometimes be tedious to refactor. Occasionally there are times when tricky run time errors sneak in that would have been caught at compile time in Java.
It also helps that I work in JavaScript a lot and have built up a large library and framework of reusable code. JavaScript doesn't come with too much out of the box.
I feel much less productive programming in JavaScript than Java. The main reason is that there are so many more portability issues with JS implementations across different browsers.
I used to feel that way as well, but as I have learned JavaScript I have also learned to get around the quirks neatly, I don't really think about browser differences when I code anymore. When there is problems it's almost always with HTML and/or CSS.
On the other hand I have never had a pleasant time writing ASP.NET, whatever I need to do, it is so hard to find any useful articles/documentation/examples. Recently I needed to interact with an MS SQL database, as seen on MSDN the "System.Data.SqlClient Namespace" contains 26 classes, each with a rich stack of methods, members, properties etc. Probably totalling around 1000 documented identifiers. One only need a handful of these to write perfectly fine code, the problem is finding this handful hidden between all the junk. Nowhere to be found is a neat little 20 lines example containing the useful functions in action (or at least if so I haven't found it). I suppose one can learn to get around the kinks of .NET and MSDN, but I fail to understand how .NET has become so widespread when there is perfectly good alternatives.
In my case:
ASP.NET -> Massive productivity fail due to wasting time finding out what function does some trivial task.
Ok here is my opinion I'm a javascript developer and is all I do, I have a good knowledge about .Net (c#) and Php, And I'm very productive with javascript as I'm in building with C#, but always depends of the application, One thing that you can't do when build with only server side code is get a fully independence between backend code and frontend code you have to mixup (server code and xhtml || css code, but with javascript and some webservice or ashx files, you can really split this issue you get a lot of good points. For example you can build two team one of frontend (designer) and the second one just of programers, And belive this is great, many times just the backend team does not think the same way of the backend team and many time have different goals in their head. The second good point and a very very good is with this you don't care about if your front end designer are building the site just with javascript or with flash wich is ecmascript (javascript flavor), or an iphone.
The bad point is that you have to know alot!!! of javascript because almost all the time you are writting code without intelligenSense or a IDE, is just you and your knowledge, you don't have many feedback from the browser when you have an error writting the code so debuggin can be a problem at least if you don't use firebug (firefox) || .NET IDE.
And for "kwyjibo" I only use a fully JAVASCRIPT AJAX solution only when the site is very complex and have to be a really really USER FRIENDLY 'cool' solution.
But yes you CAN be the same productive =)
I've always thought to myself if JavaScript went on the desktop, it would demolish Ruby, Python, and Perl as the language of choice for ad hoc scripting -- but that's pure speculation :)
But since you asked, productivity and familiarity go hand in hand. I write a few lines of JS once a year at most, so I constantly refer back to the documentation to get anything done. On the other hand, I use .NET everyday :)
I think there's some argument that Javascript is more productive than VB.NET. VB is bulky by design, and all those extra half seconds it takes to write out 'Public Property whatever As Type get ... end get set(value as Type) end set' will add up (even with the IDE filling in most of the boilerplate automagically).
C# is a little closer to JavaScript in terseness. (And speaking just for myself, I find I'm much more productive in F# than C# :) ) So you can write code in both languages at the same speed, how fast can you debug it? At least for me, Firebug is ok, but nothing in the world beats the Visual Studio debugger.
If you're finding VB.NET isn't up to snuff, you're in good company ;) Try switching to C# as your default language, see if it makes a difference.
Iam a great fan of javascript frameworks especially jQuery .I have always wanted to design sites like "plurk.com" but i know that it needs very huge lines of javascript.so that shut me off.But since i came to know GWT , i really want to test it out and want to ask you if it makes our job easier to develop complex things than with the javascript or its frameworks .Which one would you prefer ?
I think a few of the answers on this question are quite un-informed, and I suspect that the people answering them have never used GWT on large scale projects. Yes GWT is a great way to do large AJAX websites, and for large complex sites, involving a back end as well, it kicks things like JQuery up and down the park. The way I always look at it is that javascript on it's own is great for doing small client side things. When you need to do something more complex (like dynamic fields, popups, animations) you bring in something like JQuery or Prototype. When you want to take it one step further you go with GWT.
People assume that because you write it in Java, it's designed for back end developers to do front end development. It's not. Java is simply the language that they chose, mainly because it's widely used, statically typed and there are lots of good editors out there for it.
I don't buy the leaky abstraction theory either, it doesn't try to fully abstract out the HTML elements, as it gives you direct access to both native javascript and the DOM if you choose to use those.
In short we've built very complex sites (one of which was featured on the GWT blog) in GWT, and also using other libraries like JQuery. I can tell you with 100% confidence that once you get your head around GWT it kills those other frameworks dead for complex tasks. It also has some great built in things that help make things better, and even does some things that no other framework supports (like the magic it can do with images). See this blog post for more details:
http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html
Few things scare me like "generated Javascript". The Law of Leaky Abstractions has got to be doubly true in these cases.
Writing effective cross-browser javascript is a tricky process of continuous refinement. Trying to decipher where some generated, obscured Javascript is going wrong is a major headache. It's bad enough fixing bugs in the pure JS libraries.
To me, GWT is a trick aimed at allowing backend developers to write front-end, in-browser code. Unfortunately, the realities of modern web apps mean you just have to know Javascript and the DOM. Something's going to break, and you're going to need to know why.
I think you're better off picking a good javascript library like jquery or prototype, and learning that well. Those libraries abstract away the sort of stuff that SHOULD be abstracted away and is unlikely to break in edge cases, like array operations and AJAX requests.
Yes, it does, since you'll be using Java and not Javascript.
Superb IDEs, static code analysis, searching and refactoring - all this will make your life much easier on large projects.
No. It doesn't.
It doesn't remove the complexity, it just makes it possible for you to deal with it from a Java Perspective. Since that gives you all the Tooling available from Java... that alone might make it worthwhile.
JavaScript IDEs are getting better and better though, and typically if you're using a Framework like jQuery or Prototype, then you're probably going to find it easier than dealing with a heavy weight abstraction layer like GWT.
My personal preference is to take the pure JavaScript approach, but that's because I like being able to work more closely to metal, and I'm disciplined enough to tame my JavaScript cats.
With GWT, you're not actually writing JavaScript; it's entire value proposition is that you can write Java that it will compile down to JavaScript for you.
I'm working on a project that has used GWT to pretty good effect. It's a good choice for us since we're all primarily Java developers working on internal tools. I can't speak to how useful it is for large end-user sites.
One advantage I particularly appreciate is the seamless object serialization and deserialization. Not only are the details of XML-RPC abstracted away, but since the same Java code is compiled to byte code for the server and javascript for the browser, you can code almost as if the server and client were running in separate class loaders in the same JVM. For instance, you can construct a Java object on the server, send it to the browser as the return value from an RPC service call and the browser code can then use the identical Java class to manipulate the object you just returned. Likewise, parameters to RPC calls can be constructed as Java objects, with the server receiving an identical Java object on the other end. All this without mucking about in the details of (de)serialization.