Is processing Javascript Server-Side a solution to duplicated logic?

Question

Web-Applications these days make extensive use of Javascript, for example various Google Products like Gmail and Calendar.

I'm struggling to how NOT having duplicated logic server and client side.

When requesting a page or state of the application, i would prefer to send the complete UI, meaning: not just some javascript, which in turn makes a dozen ajax requests and builds the user interface.

But here lies the problem, the logic deciding what to show or not has to be written once in the server-side and once in the client-side language.

Then i was wondering if it was somehow possible to process your javascript logic server-side and send the whole to the client, who in turn can continue using the application with all the advantages of a responsive ui, but without disadvantage of the initial loading/building of the user interface due dependency of background ajax requests.

I hope the explanation of my problem is a bit clear, because i'm not the most fluent English writer. If you understand what i mean and if you can describe the problem a little better, please do... thanks!

So my question is:

• Is something like this possible and or realistic?
• What is your opinion on how to tackle this problem?

;-)

Answer 1

Seems you describe Jaxer.You can write everything in JS.
Also, there is GWT that allows to write whole thing on Java

Answer 2

I understand what you're saying.

But I don't think you should be having much 'logic' about what to build, on the client side. If you did want to go with a model like you're proposing (not my cup of tea, but why not), I don't see why you'd end up with much duplicated.

Where you would normally show a table or div, you would just output JavaScript, that would build the relevant components on the client side.

I would consider it just as another 'View' into your data/business logic model.

Have you go a small example of a problem you're coming up against?

Answer 3

When we started our web app, we had the same kind of questions.
It may help you to know how we ended:

• The backend (business logic, security) is totally separated from the frontend (gui)

• frontend and backend communicate through JSON services exclusively

• the JSON is rendered client-side with the PURE templating library

• and the backend is Erlang (anything streaming JSON would be ok too, but we liked its power)

And for your question, you have to consider the browser as totally unsafe.
All the security logic must come from the backend.

Hiding or showing some parts of the screen client side is ok, but for sure the backend decides which data is sent to the browser.

Answer 4

Then i was wondering if it was somehow possible to process your javascript logic server-side and send the whole to the client, who in turn can continue using the application with all the advantages of a responsive ui, but without disadvantage of the initial loading/building of the user interface due dependency of background ajax requests.

Maybe the apps you're looking at just use Ajax poorly.

The only content you can pre-process on the server is the content you already know the user wants. For example, in an email app, you could send them a complete view of their inbox, pre-processed on the server and fetched with a single request, as soon as they log in. But you might use AJAX to fetch a particular message once they click on it. Sending them all the messages up front would be too slow.

Used correctly, AJAX should make your pages faster, because it can request tiny updates or changes of content without reloading the whole page.

But here lies the problem, the logic deciding what to show or not has to be written once in the server-side and once in the client-side language.

Not necessarily. For example, in PHP, you might write a function like displayWidgetInfo(). You could use that function to send the initial widget information at page load. If the user clicks the widget to change something, send an AJAX request to a PHP script that also uses displayWidgetInfo() to send back new results. Almost all your logic stays in that single function.

Your instincts are correct: it's bad to duplicate code, and it's bad to make too many requests for one page. But I think you can fix those problems with some refactoring.