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.
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.
Recently I got introduced to node.js and cool packages like express and jade. I have few questions consistently knocking my door:
If I pick node.js to build my next website, I will be using JavaScript to write my server-side complicated logic? but I don't think you can compare JavaScript with Java or Python to write server-side code as they have such a vast ocean of libraries. Is node.js really meant for it? or I have missed something?
Can I call Java or Python from node.js?
Not quite sure what most of these folks are talking about.
A "vast ocean of libraries" is something the community is actively working on. Check this: http://search.npmjs.org/#/_analytics -- there were 8 packages published yesterday
Its not going to solve your software design for you. As for where and how to write business logic, many of us embrace mvc or mvvm or something close to it. If you're building an application and like how Rubyists (for example), structure their code you might look at doing something just like that -- aint nobody going to tell you how to structure your code.
Check https://github.com/joyent/node/wiki/modules
Some of the more popular libraries for doing the day to day:
Express: http://expressjs.com/ - https://github.com/visionmedia/express
Sinatra inspired, use it to build a typical web app
Stats: 3407 watchers, 286 forks, on pull request 778
Compare that to Sinatra itself! 2529 watchers, 366 forks
With connect, it supports all kinds of middleware:
sessions,
all kinds of routing,
static files
some 15 different templating engines
validation, form handling, etc, etc
Socket.io: http://socket.io/ - make it 'real-time'
DNode: https://github.com/substack/dnode - do rpc between anything
Backbone.js: http://documentcloud.github.com/backbone/ - MVC
Variety of techniques for re-using your models on the server:
http://andyet.net/blog/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
Spine.js: http://maccman.github.com/spine.tutorials/index.html - MCV
Techniques for re-using code on the server:
http://maccman.github.com/spine.tutorials/node.html
caolan/async: https://github.com/caolan/async - Help manage your async business logic
Database, pick your poision
node_redis, https://github.com/mranney/node_redis - or one of the eight other clients
"This is a complete Redis client for node.js. It supports all Redis commands"
node-mysql, https://github.com/felixge/node-mysql - or one of eleven other clients/orms
node-mongodb-native, https://github.com/christkv/node-mongodb-native
node-postgres, https://github.com/brianc/node-postgres
There's also a host of ORMs out there, if thats your bag. Things like http://mongoosejs.com/, http://sequelizejs.com/ and friends
Test-driven development is at the core of node. There are 15 different TDD packages to choose from that range from full code coverage analysis to custom assert modules.
Saying all modules are incomplete is silly. There is an incredibly dedicated group of people building and maintaining tons working open-source in this community every day.
There might be reasons to pass over node, but its not for an inactive community or lack of libraries.
I would say you missed something - more specifically, the core purpose of Node.js, that is, the asynchronous I/O model.
I started a little pet project to test Node.js - how it "feels" and how to program on it. I became impressed by the ease of working in such ecosystem: Node.js code is easy to write (although its asynchronous paradigm is not that straightforward for the conventional programmer), libraries are easy to build etc. etc. Even npm is amazingly easy: I just found the most straightforward way to provide code of your own as a library is to make a public package of it - and it is absurdly easy!
However, there is not much good tools to work with Node.js. Maybe because it is too easy to do anything, most libraries are partially-implemented, undocumented solutions.
Also, note that the relevant difference of Node.js is not the JavaScript language, but the asynchronous I/O model. It is the most interesting aspect of Node.js, but the asynchronous programming style is not as well tested as the conventional way of web development. Maybe it is really the marvel that is propagandized - or perhaps, it is not as good as promised.
Even in the case it pays off, will you have enough developers to maintain such an (at least still) unusual codebase? If you can get a lot of advantages from the asynchronous "way of life" of Node.js, you can use more consolidated languages and frameworks, such as Twisted for Python (which is my preferred languabe, so take care with my opinion :) ). There may be something like this for Java, too. Anyway, I suspect that you do not have a lot of interest in this model for now, since your question focuses more on languages than in the programming paradigm, so Node.js does not have much to offer to you anyway.
So... no, I would not develop something professonaly in Node.js for now, although I think it is both fun and instructive to study. You can do it, however - just do not do it without having in mind the main purpose of Node.js: asynchronous-IO, event-driven programming. If it is what you want, Node.js is a good alternative.
Ryan did not start with JavaScript. A large part of why Node was created in JavaScript is that JavaScript lacked vast oceans of libraries.
Those vast oceans of libraries are almost all written in blocking code.
To take full advantage of Node.js you need to limit your self to non blocking libraries. Which means that might need to write some libraries to complete your project in Node.js.
I think you'll be surprised by the amount of work you can get done in JavaScript via Node.js. There are a bunch of libraries available for Node and more are being written all the time. Furthermore, native extensions are also available for those times where you might need to drop down to a lower-level.
If you think there's a gap where Node won't be able to provide for your business logic, take a look around NPM or give Google a quick serch to see if anyone else has already solved your problem.
Of course, you can use Python, PHP, c++ or other technologies with nodejs 'cuz node can run it as a child process. Nodejs give you the freedom to use any technology which you want inside itself. You can use whatever you want combining the most performance programs.
There are some things that JavaScript just can't do. If you come up against those Node might not be the best choice for your app. However you can probably accomplish most of what you need.
As far as the API being limited, I suggest you take a look at npm and all the libraries in its repository. Specifically ones like underscore.js. Many aim to fill in the gaps of what native JavaScript lacks compared to other languages.
I want to be able to define templates once and use them to render html from both the server-side as well as the client-side. (DRY principle and all that)
The API that I'm envisioning is simply this: render(JSON, template) --> html.
I'm using a java-framework (actually Play framwork, but I don't think this is framework specific).
I've read a lot of similar questions, the latest, and most helpful being: Templating language for both client-side and server-side rendering.
I pretty much agree with the author that obvious contenders like: Mustache and Google Closure Templates are not going to cut it. (for reasons see that post)
Requirements:
MUST: client-side rendering
MUST: client-side caching of template-files
NICE: client-side 'compile-once execute many times' of template-file to fast javascript-code
MUST: server-side rendering
NICE: native java implementation
I've seen a bunch of posts suggesting the use of Node.js for server-side templating. Although this would definitely work (underscore templates, Handlebarsjs, EJS would all work just fine) I'm struggeling to see how to communicate/combine/integrate Node.js with java, after all it's still the java framework that needs to output the JSON
I've seen posts mentioning some proof-of-concept communicating between a JVM and node.js (over http or using JNDI) . However, no library, let alone battle-tested, seems to be available at the moment.
So to round things up, what client-side templating engine would you suggest that would run in java as well (or with some hoops, can be called from a jvm) ? And if that 'hoop' happens to be Node.js, what ways of communication/ library would you suggest to use?
I'm going for Mustache for now and anticipating a java implementation for Handlebars.js.
Once that exists, the refactoring-path shouldn't be that steep.
EDIT - april 2012
Ok, updating this for future reference:
I'm outsourcing server-side templating to Node.js.
communication between java and node.js implemented using sockets. (see: Sending data from node.js to Java using sockets for where I got the idea)
Since now I only need a client-lib (or better one that runs in javascript on both client and server-side using node) I can choose more freely. Having become accustomed to Mustache, I've chosen the Hogan parser (by the Twitter guys) ( http://twitter.github.com/hogan.js/ )
100% DRY (even the client-side mixins and i18N-bundles come from the same source.
Moreover, Hogan can precompile the templates server-side and open a connection to the client so the client doesn't have to parse the template anymore on first connect.
Is it fast? Lightning...
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.
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.