We Keep Coding

What is the Difference between Client Side & Server Side Rendering?

Ok, I've been working on a Node Js course & I'm a bit confused as of what is the difference between client side & server side rendering.
1st Question: What is the purpose of using front end in the client side WHEN you can just serve up HTML/CSS Through the server side back-end by using app.use(express.static(__dirname, 'public')? from my understanding it accomplishes the same thing.
2 Question: What is the purpose of front-end if you can just accomplish the same thing by using app.get() on an express server.
I'm really confused on front-end and back end and when it is appropriate to use front end/ express.static() OR just serving up files on the express server. Please explain your answer in the easiest way and not a bunch of tech jargon.

This is a question that implies opinionated answers, which is not the purpose of StackOverflow. I'll still provide an answer with factual arguments.
The pros of client-side rendering over server-side rendering is that it improves user experience by never reloading the page. The network usage is reduced to a minimum (only data to display, in JSON which is a very light format) which makes it faster overall. You can also do things like animate navigations, etc...
On the other side, it takes more time to start because of the size of the JS files (often several MB), and it's less SEO-friendly (Google has improved on this since they no longer use Chrome 41 for their GoogleBot, but it still doesn't index client-side rendered sites very well).
Most JavaScript frameworks abstract DOM manipulations, and allow client-side to get along with server-side, since JavaScript can execute in browsers and in Node.js. This allows to benefit from the best of both worlds.

Relation between ExtJS Direct and DirectJNgine

Am new to ExtJS Direct and DirectJNgine. The relation between them confuses me. I cannot get the overview picture.
What I know is:
ExtJS is a JavaScript framework focusing on UI design. It supplies plethora APIs for programmers. I can call these APIs without bitter.
From the official site:
Ext Direct is a platform and language agnostic technology to remote server-side methods to the client-side. Ext Direct allows for seamless communication between the client-side of an Ext JS application and all popular server platforms.
My think is: ExtJS Direct is also a subset of the APIs supplied the ExtJS team for us to use. These APIs can facilitate our work on calling server side method. But I want to dig into a little bit.
Server side method can be any language method, like JAVA C++ PHP etc. Direct APIs handle all possibilities to support different server side language methods?
From the official site:
DirectJNgine (or DJN, for short), is a Java based implementation of the Ext Direct API for ExtJs.
ExtJs is probably one of the most powerful and attractive UIs for web-based applications, as can be seen here, as well as in many other examples. DirectJNgine makes it much easier to use the full power of Java business classes with such a powerful front-end, making Java methods directly callable from the client.
Since ExtJS Direct is already implemented the APIs for seamless remote method invoking. Why DirectJNgine need to implement these ExtJS Direct APIs? What does "a java based implementation of the Ext Direct API for ExtJs" mean?

I'd add server-side to the definition DirectJNgine:
DirectJNgine is an Open Source library that provides a Java-based implementation of the server-side Ext Direct API.
Ext Direct is a javascript framework and resides on client and let's you call any server API. The call is made via HTTP - that's why it's not dependent on the server language. You formulate a HTTP request, not a Java/PHP/any other request.
Server API handles the HTTP request and can be implemented in Java, C++, PHP, .Net etc. One of the Java implementations is DirectJNgine. It runs on server and responses to Ext Direct calls.
In your project you can use both Ext Direct and DirectJNgine for communication between client and server. They don't overlap, they cooperate with each other on the opposite sides of the network.
And you'd use some framework for the presentation layer (ExtJS maybe) and some framework for server business/storage/other layers (to make use of DirectJNgine it would be a Java framework).

Extjs needs to know the URL, the methods and the parameter count for the possible actions and this is provided by for example DirectJNgine.
The API also takes care of messaging between ExtJS and JAVA , i.e. converting incoming JSON objects to JAVA methods (Json with method names and parameters is passed to JAVA methods, their can be multiple actions in one call). And passing back the result from the JAVA methods in JSON format.

I did a bit of digging into extdirectspring when I realised some strange stuff was going on and wanted to know why. Effectively what extdirect does is provide a description of the server side methods to the client in the form of json (+ possibly through other mediums).
On the client side you end up with objects built from this json that know how to call the server code. In the java (extdirectspring) implementation this creates a static variable in your program's namespace for each of the java classes decorated with the 'ExtDirectMethod' attribute. This variable seems to always be the class name with the first letter lowercased. I had a bit of a dig and this appears to be by coincidence - the name comes from the bean name in spring and is not defined by extdirectspring.
In extdirectspring the setup works through the ether (through the servlet + spring) (have yet to bottom out exactly how this works) and it is predefined to respond to requests for api.js (among other things). This then returns the configuration object which is assigned to a static variable in the ext namespace. By default this variable is called REMOTING_API.
To get the client side stuff to know about what the server has to offer you need to put in a call like:
Ext.direct.Manager.addProvider(Ext.app.REMOTING_API);
after extjs has fired up.

Is there a web stack optimized to minimize server-side coding?

For a couple recent projects on our corporate intranet, I have used a very simple stack of nginx + redis + webdis + client-side javascript to implement some simple data analysis tools. The experience was absolutely wonderful, especially compared to my previous experience with other stacks (including custom c++, apache/mod_perl, ASP.Net MVC, .Net HttpListener, Ruby on Rails, and a bit of Node.js). Given the availability of client-side templating tools and frontend libraries such as jquery-ui, it seems that I could happily implement much more complicated web-apps using such a no-server-side-code stack (perhaps substituting/augmenting redis with couchdb if warranted)...
The major limitation of this stack, of course, is that my database is directly exposed to the network - acceptable in this case on a firewalled corporate network, but not really an option if I wanted to use the same techniques on the internet. I need to have some level of server-side logic to securely handle authentication and user-role management.
Are there any best practices or common development stacks for this? Ideally I'd like something that is lightweight, and gives me a simple framework for filtering the client-side requests through my custom user-role logic before forwarding them on to the database back-end. I'm not interested in any sort of server-side templating, or ActiveRecord-style storage-level abstractions.

I can't comment on a framework.
You've already mentioned the primary weakness of this, especially on the internet, that being security. The problem there is not just authentication. The problem there is essentially the openness of the client, in this case the web browser, and the protocol, notably HTTP using JSON or XML or some other plaintext protocol.
Consider one example. It's quite simple. Imagine an HTTP service that takes an SQL query and returns a collection of JSON representing the rows. This is straightforward to write. You could probably pound out a nascent one in less than an hour from scratch using any tool that gives you SQL access to an RDBMS.
Arguably, back in the Golden Days of Client Server development, this is exactly what folks did, only instead of a some data tunneled over HTTP, folks used a DB specific driver and sent SQL text over to the back in DB directly.
The problem today is that the protocols are too open. If you implemented that SQL service mentioned above, you essentially turn your entire application in a SQL injection vector.
You simply can not secure something like that in the wild. The protocol is open to trivial observation (every browser comes with a built in packet sniffer, effectively today), along with all of the source code for the application. If you try to encrypt the data, that's all done on the client as well -- with the source to the process, as well as any keys involved.
CouchDB, for example, can not be secured this way. If someone has rights to the server, they have rights to all of the data. ALL of the data. The stuff you want them to see, and the stuff you don't.
The solution, naturally, is a service layer. Something that speaks at a higher level than simply raw data streams. Something that can be secured, and can keep secrets from the clients. But that, naturally, takes server side programming to enable, and its a ostensibly more work, more layers, more data conversion, more a pain.
Back in the day, folks would write entire systems using nothing but stored procedures in the DB. The procedures would have rights that the users invoking them did not, thus you could limit at the server what a user could or could not see or change. You could given them unlimited SELECT capability on a restricted view, perhaps, while a stored procedure would have rights to actually change data or access some of the hidden columns.
Stored procedures have mostly been replaced by application layers and application servers, with the DB being more and more relegated to "dumb storage". But the concepts are similar.
There's value for some scenarios to publishing data straight to the web, like you analytics example. That's a specific, read heavy niche. But beyond that, the concept doesn't work well, I fear. Obfuscated JS is hard to read, but not secure.
This is likely why you may have a little difficulty locating such a framework (I haven't looked at all, myself).

is json the answer to this: python program will talk and javascript will listen?

the same problem haunting me a month ago is still haunting me now. i know ive asked several questions regarding this on this site and i am truly sorry for that. your suggestions have all been excellent but the answer is still elusive. i now realize that this is a direct result of me not being able to phrase my question properly and for that i am sorry.
to give you guys a generalized view of things, here i go: the situation is like this, i have 2 server side scripts that i want to run.
a python program/script that continuously spouts some numbers
based on the output from that python script, a javascript script will perform some action on a webpage (e.g., change background color, display alert message, change some text)
ive studied the replies to my previous posts and have found that what i want to accomplish is more or less accomplished by json. it is my understanding that json transforms 'program-specific' variables into a format that is more 'standard or general or global'.
two different programs therefore now have the means to 'talk' with each other because they are now speaking the same 'language'.
the problem is then this, how do i actually facilitate their communication? what is the 'cellphone' between these server side scripts? do they even need one?
thank you!

If I understand what you're asking, the "cellphone" is TCP/IP. The javascript is not server-side; it runs on the client side, and alters what the client's browser displays based on json data that it downloads from the server -- data that in this case is generated by Python.
This question provides a relevant example, though it's a bit technical: JSON datetime between Python and JavaScript
Here's a very basic tutorial that explains how to create a dynamic webpage using python and javascript. It doesn't appear to use json, but it should familiarize you with the fundamentals. Once you understand what's there, using json to transport more complicated data should be fairly straightforward.
http://kooneiform.wordpress.com/2010/02/28/python-and-ajax-for-beginners-with-webpy-and-jquery/

I assume you mean: Python is on the web server, and Javascript is running in the client's web browser.
Because browsers are all different (IE6 is terrible, Chrome is great), there are a huge number of ways people found to "hack" this "cellphone" into place. These techniques are called AJAX and COMET techniques. There is no one "cellphone", but a whole bunch of them! Hopefully, you can find a library to select the right technique for the browser, and you just have to worry about the messages.
Comet is harder to do, but lets the server "push" messages to the client.
Ajax can be easier - you just periodically "pull" messages from the server.
Start with Ajax, then look at comet if you really need it. Just start by have the client (javascript) make a "GET" request, to see if the number has changed.

I don't know Javascript or json, but...
if you've ever seen an Unix-like operating system, you know about pipes. Like program1 | program2 | program3 ... Why don't you just connect Python and Javascript programs with pipes? The first one writes to stdout, and the next one reads from stdin.

This probably isn't the answer that you are looking for, and without links to your previous posts, I don't have much to go on, but nonetheless...
javascript is client side. I can interpret your question 2 different ways...
Your python script is running on your computer, and you want a script to actually alter your current browser window.
Not too sure, but writing a browser plugin may be the answer here.
Your python script is running on the server, and as a result of the script running, you want the display of your site to be changed for viewing persons.
In this case, you will could use ajax polling (or similar) on your site. Have your site be polling the server with ajax, call a server method that checks the output of the script (maybe written to a file?), and see if it has changed.

When 2 process need to communicate, they need to decide of a common/shared way to express things and a protocol to exchange those things.
In your case, since one of the processes is a browser, the protocol of choice is http. So the browser needs to do an http request or regular http request to your python process.
This python process Will need in Some way or another to be exposed via http.
There are several ways to build a web server in python. You should read this article : http://fragments.turtlemeat.com/pythonwebserver.php as a jumpstart.
Once you have this, your browser Will be able to issue HTTP GET requests to your server and your server can reply with a string.
This string can be whatever you like. Nevertheless if your answer contains structured data it can be a good start to use the XML notation or the json notation.
Json (stands for Javascript object notation) is very easy to use in javascript and this is why many people advised you to choose this notation.
I hope this will help you
Jérome wagner

Do I need server-end knowledge (e.g. Django, Rails), if I want to do Javascript, AJAX stuff?

I am trying to get into web development, specially interested building the front-end, UI part of websites while learning JavaScript maybe with AJAX technology. (I have a UI, HCI background.)
However, I have absolutely no previous knowledge about server-end web development either. To my understanding, frameworks like Django seem to pretty good at this (correct me if I am misunderstanding).
So the question is: how much Django, or Rails do I need to know, if my interest is primarily the user interface part of web development. Can I just let somebody else do the back-end stuff?
Pardon me for my imprecise choice of terminologies.

You need to know a bit about the server side. Here's what you need to know.
If you have a heavy JavaScript website, you're likely going to want to pass information from the server to clients with JSON (JavaScript Object Notation). This is just a way to format data into strings that JavaScript knows how to convert to objects.
So, each of your server-side functions that send data to the client will return JSON. If you have someone writing the server-side for you, that's all you should have to know. You're JS functions will receive JSON, and then you deal with it.
If you have to write the server-side yourself, then that involves 1) getting data from database 2) formatting the data 3) converting to JSON.
I have open-sourced a commenting widget that accepts JSON messages, and gives examples of how you would set up the Django server code. Maybe it will help you: http://www.trailbehind.com/comment_widget/

You can make a career of front-end user interface development without know a ton about server code. You would do well though to have at least a rudimentary understanding of what happens on the server when you send it a request, where your data comes from, and what the life-cycle of a web page is. This assumes that you have the support of back-end developers. As you mentioned Ajax in your question that implies that you want your web sites to actually do something, which will require things to happen on the back-end (such as storage, manipulation of data, logging in a user, etc.).
As with all things, the more you know, the easier it will be to get what you want from the dedicated professionals. I would suggest that you learn about programming in general, not try an learn a language and framework. In particular, try to understand datatypes, server settings (like timeouts, post versus get, etc.), security and database interactions as they exist beyond JavaScript/ECMAScript. That way when a developer is explaining why they cannot do something you have requested or are offering alternatives, you are speaking the same language.

Yes and no. Typically what people think of AJAX, such as posting a comment on YouTube and seeing the comment appear instantly with a thank you message, for example, requires a server side language handling the requests, looking up data and returning results as html snippets, JSON data, or XML.
However, an AJAX call can be made to static resources as well. You could have an XML file or html snippet stored statically on your web server and have it loaded. The uses for this sort of static loading are generally fewer because if you already have the static html or data in file next to your regular page, why not just put that data directly into the page?

It helps to set up a local server and write a few lines of code to service your AJAX calls. You can do a lot of JavaScript learning with just a little back-end learning.

If you're new in web development you'd rather wait with Ajax and server-side languages until you've learnt the basics with HTML, CSS and JavaScript, especially if you want to mostly work with the user interface and not the funcionality.

As you said you can let somebody else do the back-end and focus on front-end (JavaScript, HTML, CSS).
You would need to communicate with the back-end developer when storing or processing data from the server.
As mentioned before back-end development knowledge would be useful but if you have someone doing it, it's not essential for beginning.