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...
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.
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.
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 have a bunch of Java code which was written using the Hibernate framework, originally destined to have a front end written using JSPs. However, the requirements for the front end have changed, and we've decided that a desktop client (which will be written in .NET) is a better match for our users.
I don't really want to waste the code that's already been written - can anybody suggest a good set of tools for writing a document-based web services interface that we will be able to access from .NET?
Thanks,
Jim
If you truly want a document based service interface (rather than an RPC style web service architecture), your best bet is going to be creating a SOAP based web service interface.
A quick glance at the Java site shows that the Metro stack might help a bit:
Java Web Services at a Glance
We're developing an application with the exact architecture you describe for a finance application. We reviewed several different options, and have finally landed on using compressed CSV over HTTP.
CSV was chosen since the vast majority of data was going to be displayed in a grid on the front end, we had very large result sets >250k rows on a regular basis, and it compresses really really well.
We also looked at using:
ICE, but declined on that due to licensing costs and the need to reinvent so much.
Google's protocol buffers via servlets, but declined on that due to lack of C# support (as of last fall).
Compressed XML using WOX, but declined on that due to lock-in to a small thesis project for support and XML being too verbose.
The industry supports a couple of different options as well:
SOAP, but that has its own well documented issues.
IIOP, J-Integra has a product called Espresso which will allow you to do RMI from a front end.
I'd personally use some lightweight RPC protocol, be it XML-RPC or a homegrown one. SOAP, IMO, is way too fat and is not as interoperable as it's supposed to be. The simpler the better.
We have a quite large application using a Java RMI server and IIOP.NET for interoperability. We have used IIOP.NET with the Sun RMI and the Bea Weblogic (now Oracle) without major issues.