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.
Related
I'm new to server side javascript programming, and I'm trying to understand the differences between this and the traditional server side java.
What are the significant differences and why is SSJS becoming popular? How is SSJS better than Java?
From a layman's perspective, I would assume JS to be slower than Java in terms of performance, primarily because of it being an interpreted language.
Regards,
Anand
I think node.js has had a lot to do with the rise of this phenomenon:
http://nodejs.org/
Pretty sure it has been the impetus for a lot of the commonjs library development, etc.
I see comments to the effect that it makes lives easier when the client and server side code is in the same language. For the node project I worked on, there were only 3 programmers for everything initially, and we were more-or-less given carte blanche to use whatever technology we wanted. This led to some debate as everybody had different backgrounds; but when somebody suggested nodejs, one reason it seemed like a good idea was that javascript was something we all had in common.
However, I don't think the success of node is mainly because it uses js; it's about the design. I liked it a lot more than most of the other server side technology I've worked with (Rails, PHP, cgi, mod_perl, mason), and I would probably have liked it just as much regardless of the language used in the interface. But js it is.
So that's my point: I think it has less to do with anything in particular about javascript and more to do with some of the clever thinking and development that has gone on in the "javascript community", surprise surprise. Consider PHP: I don't think the success of PHP had much to do with the design (or performance characteristics) of the language, I think it had to do with the nature of how it is used and how people conceived of server side programming 10-15 years ago, and (closely related) the tools they had to build upon.
One issue there (in the "clever thinking" department) is the (very convincing-if-you-try-it) assertion made by the people behind node and, eg, nginx, to the effect that an asynchronous, event driven model is better suited to server programming than the traditional parallel synchronous, thread driven model. I believe the later predominates in java, even tho methinks it could just as easily be used the other way. Javascript, on the other hand, was originally intended for use in the asynchronous, event driven world of the browser, and doesn't have threads at all. Again: not so much the language, but the culture.
Also worth noting is the predominant use of JSON as an interchange format and of NoSQL databases like couchdb (which I've used) and mongodb (which I haven't), that make fundamental use of JSON in structuring the db. Couchdb also uses js for some server side programming (basically, query handlers), presumably because the database documents are in JSON, which is also nice to hand off to the client. Very slick and clever. One language, one protocol, from model to view; in a significant sense, there is no "interchange" at all.
the differences between this and the traditional server side java
First of all, Java and JavaScript have nothing in common. They are two totally different things. Keep that in mind.
I think many people like server side JavaScript, because they can stay in one language. They use JavaScript on the server as well on the client, instead of using another language (like Java, PHP or Ruby). Also, a lot of web programmers are familiar with JavaScript (because they use it on the client), so they understand it well.
JavaScript can also be easier as Java. If you have just a small project, Java could be a lot of overhead compared to JavaScript. Some things like callbacks could be very elegant in JavaScript.
Also, new frameworks like Node.js make it attractive to use this language. As long as there wasn't any server side framework, you simple couldn't use JavaScript on the server. But the language has evolved well today.
I think the performance of JavaScript depends also on the server. I'm not sure of this, but as far as I know, JavaScript could be (just in time) compiled, too. Google's chrome is doing something like that. Also, performance isn't such a big thing on most websites, because the performance is mostly IO to a database. The actual creation of an HTML page is very simple and no big thing. And: PHP is also interpreted and used on many sites. Ruby is significant slower then Java, but Ruby on Rails is very popular. So performance seems not so important. It's more about how "nice" and elegant the language is.
The main advantage from my point of view is simplification of client-server interaction if you have rich JS client interface. If you use the same language at server and client side you can share common code between them (for example, if you have some business logic like validation and it is used at client and at server you can implement it once in JS and use in several places).
And if you already know JS you should not learn a new language to do server-side work.
It's like why using GWT (java web client from google) when you have such wonderful thing like JS.
It's more psychology question I think- people tend to stay in their own save and known zone, instead of moving to an unknown language.
If you used java in the last 5 years, and you know all it's pitfalls, and you love it very much, you'll start convince yourself that every thing should be written in java, and is the quickest solution.
I don't say that Java is better than js (although I think that it's better for large server-side projects), but I think that most of the js-server-side users uses this because they already comfort with js, so they don't want to change it.
I would like to add my point here.
In one sentence: Node.js shines in real-time web applications employing push technology over websockets.
After over 20 years of stateless-web based on the stateless request-response paradigm, we finally have web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely.
This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it’s all based on the open web stack (HTML, CSS and JS) running over the standard port 80.
We want to write a UI that consists of HTML, Javascript (JQuery) and CSS. Although the initial starting point will be served up by a web server, there won't be any sever side templating. The browser will interact with the server via a restful interface and render its UI.
What are the risks of this approach?
Ideally I'd like a nice, straightforward javascript OO api which underneath makes http calls to the server to get JSON representations of resources. Any suggestions as to how this could be structured?
Anyone have experience with browser side templating?
Is there a framework to make this style of development easier?
We will also be defining the server side resources and my thoughts are to follow ruby on rails conventions. For example, if you define a Users resource in routes.rb, you have 7 uri templates. Any thoughts?
By the way, the server side functionality will be developed in java.
I have plenty of experience with this approach. I can guarantee you that it works - how well in the long run, I don't know yet but I'm extremely happy with it (as a developer).
You do need to make sure that you've mastered Javascript. Read up on the state of the art, at least check Douglas Crockford's work, and most notably JSLint.
As for frameworks, this is where your vision comes in. We've built one from scratch because we need a combination of tools that existing frameworks don't and because we think we have the vision and expertise to carry it through. You have to compare the pro's and con's. If you use an existing framework you have very little control over it's direction or the speed at which bugs are found and fixed. If you build one yourself you could run the risk of making wrong decisions and ending up with a framework that doesn't quite work.
I have noticed that in our applications the custom server side code is only very small. This means the importance of the backend is only very small (validation, sanity, authorization). We use PHP, but simply because we have loads of experience with PHP.
There are definitely risks. In the startup and early transition I have noticed that 'lesser' programmers have trouble catching up. There is a very steep learning curve for anyone not too familiar with Javascript and it's many elegances.
Another risk is performance. We're advising our customers to use Google Chrome, simply because
And then there is compatibility. The idea of a framework is that it's able to hide this complexity. Luckily browsers are increasing in-tune in accordance to standards but backwards compatibility with (for instance) IE6 is incredibly difficult.
I would advise against using jQuery. I find jQuery more of a 'plugin' than an actual framework. jQuery really shines when you have a website and you want to sprinkle on some fanciness. It has some very good general tools (DOM manipulation and all that) but it's very lacking in the business-modeling area.
I would also advise against an OO approach. For some very small number of domains OO is the perfect solution. For most businesses, it's not. And Javascript is capable of so much more than just OO.
The #1 problem (and, perhaps, the only problem) is search engine. It is not sure how well will your content be recognized/crawalble/searchable. The underyling cause is that the search engine is not necessarily going to understand your content (since it is only revealed once Javascript gets executed).
Other than that, it is a great approach. I tried it several times and it works great (assuming you're not intimidated by Javascript). The resulting web-site is usually much more responsive than traditional web-sites since the server -> client traffic is quite small - only the raw data is transmitted. All the UI stuff is generated, by Javascript, on the client side.
As a summer learning experiment, I'm thinking of coding up a web front end for a trading game i wrote in python, that generates share prices and random snippets of text.
I am sort of struggling with how this should work on the back-end though. I'd rather have my GWT client page interact with the python share price generator, than to try and re-code it in java. I suppose i could use an sqlite db, and then use jdbc to pick up the prices, but i was wondering if there is a better way, for me to be able to poll some python script either from my client page, or from the serverside java code ?
I found this python wrapper, but i'm not sure how i could use it though:
http://code.google.com/apis/visualization/documentation/dev/gviz_api_lib.html
Thanks.
Make no mistake, GWT is a Java technology. You could perhaps interoperate by using Jython to compile your Python code but your UI will basically need to be written in Java (wrappers are second class citizens here). The reason is that the RPC protocol is proprietary and even though GWT is open I believe the compiler that takes the Java source and creates the Javascript (including the RPC calls) isn't.
With Python you might be better off using an RIA Javascript framework like Yahoo UI (YUI), ExtJS, etc. Uki also looks interesting. To give you an example of Uki, here is google Wave layout in 100 lines of Javascript.
I second #cletus' recommendation to go for real javascript plus a JS framework (though as the framework I'd suggest any of jquery, dojo, or google closure -- sorted in order from low to high "formality" -- but I guess that's a question of taste).
If you want a Python-based GWT-like approach, try pyjamas -- but it's not as rich and mature as GWT, so, unless your browser-side needs are really very modest, JS + framework is just a better approach.
Yes you can. Using JSON, you can basically use whatever back-end language you want with GWT. See this page for more detail.
GWT is a powerful tool but nonetheless a complicated one. If you take the time to learn how to use it efficiently, you'll be rocking your way through building you front-end code. You'll also find the Google plugin for Eclipse to be quite a joy.
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.
On my current project, we've been using Struts 1 for the last few years, and ... ahem ... Struts is showing its age. We're slowly migrating our front-end code to an Ajax client that consumes XML from the servers. I'm wondering if any of you have migrated a legacy Struts application to a different framework, and what challenges you faced in doing so.
Sure. Moving from Struts to an AJAX framework is a very liberating experience. (Though we used JSON rather than XML. Much easier to parse.) However, you need to be aware that it's effectively a full rewrite of your application.
Instead of the classic Database/JSP/Actions scheme for MVC, you'll find yourself moving to a Servlet/Javascript scheme whereby the model is represented by HTTP GET requests, actions are represented by POST/PUT/DELETE requests, and the view is rendered on the fly by the web browser. This leads to interesting challenges in each area:
Server Side - On the server side you will need to develop a standard for exposing data to the client. The simplest and easiest method is to adopt a REST methodology that best matches your data's hierarchy. This is fairly simple to implement with servlets, but Sun also has developed a Java 1.6 scheme using attributes that looks pretty cool.
Another aspect of the server side is to choose a transmission protocol. I know you mentioned XML already, but you might want to reconsider. XML parsers vary greatly between browsers. One browser might make the document root the first child, another one might add a special content object, and they all parse whitespace differently. Even worse, the normalize() function doesn't seem to be correctly implemented by the major browsers. Which means that XML parsing is liable to be full of hacks.
JSON is much easier to parse and more consistent in its results. Javascript and Actionscript (Flash) can both translate JSON directly to objects. This makes accessing the data a simple matter of x.y or x[y]. There are also plenty of APIs to handle JSON in every language imaginable. Because it's so easy to parse, it's almost supported BETTER than XML!
Client Side - The first issue you're going to run into is the fact that no one understands how to write Javascript. ESPECIALLY those who think they do. If you have any books on Javascript, throw them out the window NOW. There are practically no good books on the language as they all follow the same "hacking" pattern without really diving into what they are doing.
From the lowest level, your team is going to need remedial training on Javascript development. Start with the Javascript Client Guide. It's the de facto source of information on the language. The next stop is Douglas Crockford's videos on Javascript. I don't agree with everything he has to say, but he's one of the few experts on the language.
Once you've got that down, consider what frameworks, if any, you want to use. Generally speaking, I dislike stuff like Prototype and Mootools. They tend to take a simple problem and make it worse. None the less, you can feel free to evaluate these tools and decide if they'll work for you.
If you absolutely feel that you cannot live without a framework because your team is too inexperienced, then GWT might fit the bill. GWT allows you to quickly write DHTML web apps in Java code, then compile them to Javascript. The PROBLEM is that you're giving up massive amounts of flexibility by doing this. The Javascript language is far more powerful than GWT exposes. However, GWT does let Java developers get up to speed faster. So pick your battles.
Those are the key areas I can think of. I can say that you'll heave a sigh of relief once you get struts out of your application. It can be a bit of a beast. Especially if you've had inexperienced developers working on your Struts model. :-)
Any questions?
Edit 1: I forgot to add that your team should study the W3C specs religiously. These are the APIs available to you in modern browsers. If you catch anyone using the DOM 0 APIs (e.g. document.forms['myform'].blah.value instead of document.getElementById("blah").value) force them to transcribe the entire DOM 1 specification until they understand it top to bottom.
Edit 2: Another key issue to consider is how to document your fancy new AJAX application. REST style interfaces lend themselves well to being documented in a Wiki. What I did was a had a top level page that listed each of the services and a description. By clicking on the service path, you would be taken to a document with detailed information on each of the sub-paths. In theory, this scheme can document as deep as you need the tree to go.
If you go with JSON, you will need to develop a scheme to document the objects. I just listed out the possible properties in the Wiki as documentation. That works well for simple object trees, but can get complex with larger, more sophisticated objects. You can consider supplementing with something like IDL or WebIDL in that case. (Can't be much worse than XML DTDs and Schemas. ;-))
The DHTML code is a bit more classical in its documentation. You can use a tool like JSDoc to create JavaDoc-style documentation. There's just one caveat. Javascript code does not lend itself well to being documented in-code. If for no other reason that the fact that it bloats the download. However, you may find yourself regularly writing code that operates as a cohesive object, but is not coded behind the scenes as such an object. Thus the best solution is to create JSDoc skeleton files that represent and document the Javascript objects.
If you're using GWT, documentation should be a no-brainer.
Check out the Stripes Framework. If you are familiar with struts then stripes will make sense to you, but it's so much better. They have a Stripes vs Struts section on their website. You could check that out and see if it interests you. It allows you to work with any ajax framework you want, and I don't think it would take long to migrate from struts to stripes.