I know this a fairly common question but after reading a lot I still can't understand this concept.
What I understand so far is that the main difference about a server side and a client side language is that the first one needs to be interpreted by the server to be sent to browser and the second one doesn´t.
I've worked with Vaadin and I know that is a server side framework because the java code needs to be interpreted to HTML and Javascript to be sent to browser. But then I've read that GWT is a client side and I can't understand why because we design all the page elements with Java widgets and they need to be interpreted to HTML and Javacript right? So, shouldn't GWT be a server side framework?
And what about JSF? I'm working with Primefaces and I develop xhtml files that uses beans to get server information. That means that the xhml files are client side and the Java beans are server side right?
Thanks!
It's not about the language the code is written, it's about where it runs.
GWT is a client-side technology just like TypeScript or CoffeeScript: they first have to be compiled or transpiled (a true compilation in the case of GWT) to JavaScript. The compilation has to be done at build time, before you deploy the app to your server. Once compiled to JavaScript, you don't need a server: the scripts can be packaged into browser extensions, mobile apps, or just run out of the filesystem (or be deployed to a Node.js server to run as server-side code !).
You can draw a parallel with Dart: dart2js converts Dart code to JavaScript so it can run in the browser, and/or you can run Dart code in a DartVM on the server side.
JSF is a server-side technology: things run in the server and generate code (HTML, JavaScript, CSS) to be interpreted by the browser (client).
I can't really tell for Vaadin as I don't know its architecture. If GWT Widgets have to be compiled upfront, then it'd be a server-side technology, generating highly dynamic web pages (so they could even run offline). If it compiles GWT widgets on-the-fly, then it'd be a bit in between; but it's primarily a server-side technology.
Vaadin use GWT to keep client-side code base in Java. GWT compiles Java code into browser dependent JavaScript. Without GWT all code should be written in JS. Vaadin is RIA application framework, so managing complex widgets code (look into Table source code) with pure JavaScript would be painful and not easy. You can write some logic in client side and also you can use pure JavaScript in Vaadin7. It's easy to extend and gives solid foundations to write good and rich UI with minimal use of the JavaScript.
Related
We have an application in pure JSP/JQuery which we are trying to move to ReactJs for maintainability. One of the benefits of ReactJs I am seeing is server side rendering. However, all the examples I have seen of server side rendering utilize Node.js as a server side. We are currently using Tomcat and not so much inclined to deploy node.js just for server side rendering.
I have considered few alternatives such as using Nashorn (http://winterbe.com/posts/2014/04/05/java8-nashorn-tutorial/)
However, Nashorn doesn't seem to be production ready.
Has anyone deployed React.js with server side rendering on Tomcat on production?
Trying to render a Javascript app serverside without NodeJS is an excellent way to torture yourself. Trying to run javascript inside a jvm is even worse. I would recommend against it.
It is possible to render the complete client server side using PhantomJS (which technically runs without Node) or even using xvfb and Chrome on *nix. All have been done, with various degrees of painful debugging.
Running the javascript inside tomcat itself is rather unusual… I can't see the point other than "because we can". My best guess is that nobody is doing that in production.
Why not take a step further with server-side rendering and make real-time single-page web applications in reactive style without Node.js in plain Java language?
The Reactive Server Pages project uses the approach similar to the Elixir Phoenix Live View or Scala Korolev frameworks.
Motivation:
Responsive web UI in familiar Java, no client-server APIs, no JS
frameworks and npm dependencies management needed;
Lightweight SSR generated almost plain HTML page to be SEO friendly;
UI components are regular Java classes;
Brings application rendering workload and UI logic from a client's browser to the
server, your code always stays on your server;
Debug UI code as any normal Java code;
Built with Java web standards, currently runs on Jetty, but in
theory, should work on Tomcat as well.
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
I was looking for real information about this, I am working some system on Java EE, I worked all my life on web, now I am getting into systems, my boss told me he makes javascripts works from "server side" to manage polls and stuffs, still I didnt think was right and I told him I thought javascript was only executed client-side, still seems like its right, I found both information about saying it is possible and it is not, anyone has some valid answer about this? and if yes, how is this possible?
Thanks!
You can indeed execute JavaScript on the server-side with third-party packages like node.js, Mozilla Rhino, or similar.
However, it's unclear to me from your description whether he wants you to actually execute JavaScript from the server-side, serve JavaScript content from the server-side, or use AJAX to make remote-procedure calls to server-side code.
The scripting API is in the javax.script package available in the Java SE 6 platform.
Refer Link :-
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/scripting/
You can execute javascript on server side too which means that develop server centric code on server side for etsblishing connection, serving HTML files etc.All these things can be done on using server side javascript.There are so many frameworks that are used to achieve this.The main objective of running serve side javascript is to execute server side functionalities.One such example is maintinaing long-lived connections with the client.
Nod.js is such a framework which is used to implement the above said functionality.Apart from this, there are other server side javascript frameworks as well.RhinoJS is can be used to execute execute javascript in server side when running in a Java Virtual machine.
However,the idea using the server side javascript frameowork will vary depending upon your requirements.
The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?
Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.
I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.
Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.
Since GWT is cross-compiled to javascript, only a few JRE packages are emulated. What if I need to make complex computations with packages not supported by the GWT x-compiling?
Is there a way to create a separate java app that can be invoked from the client side GWT (which would of course need to be shipped with the client). I don't want to ask the server to compute stuff that can be done by the client.
For example, I have a computer imaging library that could perform stuff for me without invoking the remote server.
Thank you.
If you can do something using pure Javascript/Javascript library you can use it straightway within GWT using JSNI. JSNI is basically a bridge to write Javascript within client side java code. Thus if you find yourself stuck trying to figure out how to do things in GWT which can easily be achieved using Javascript, either using plain Javascript or using 3rd party Javascript libraries, use JSNI.