Client Side VS Server Side Basics

Client side vs server side basics

Client side programming includes any coding or computation or effects or annimation or any sort of interaction your website performs with the user via browser. But server side programming is that which performs all the task in the server only. So the user is unaware of that.

For example, PHP is used for server side programming. You design a website with HTML and use JavaScript in it to take some input from user and modify it in anyway. To be more specific, if you created a blog website and you want to specify that the user can post a max of 5000 characters. Then you do some client side programming with JavaScript to count the number of characters and any filtering or anything. But then you need to send those posts to the server. The server then performs some server side task, may be with PHP, to sanitize the input for SQL Injection and saves it into a database.

User will only know what happened in the browser but not what happened in the server. Those are background tasks.

Difference between Client-Side JavaScript, Server-side JavaScript and CoreJavaScript

Without knowing the book, I can't tell you what is the meaning of CoreJavaScript, but in what concerns to the first two the difference is:

Client side javascript as the name says, is javascript code, running on the client side, a typical scenario of this is, when you access a website, and you run javascript code. The code being executed is being executed on the clients machine. This is why it's called client side javascript.

About the second, server side javascript, is javascript code running over a server local resources, it's just like C# or Java, but the syntax is based on JavaScript, a good example of this is Node.JS, with Node.JS you write javascript to program on the server side, and that code can be seen as normal C#, C, or any other server side language code.

With server-side code, you can still send javascript to the client-side, but there is a great diference between both, because the client side code is restricted to the clients machine resources, in terms of computing power and permissions. For example client-side javascript can't access the clients hard disk, while with server side you can access your server hard disk without any problem.

UPDATE

I've read a bit of the book, and Core JavaScript is about the JavaScript language per se (JavaScript Reference), i.e, the syntax, the statements, the function definitions, it's the basics of the language in general.

Imagine you are reading about C# or Java, before writing about Sockets Programming, WebServices, etc, the book is giving the reader an insight of the language first, in terms of it's capabilities, ways to create functions, arrays, and so forth.

Server side programming vs Client side programming

There are several typical software architectures:

• Non-networked application (does not communicate, client-only)
• Server-client application (has typically one or more central servers, and multiple clients that contact the server(s))
• Peer-to-peer application (only has clients that communicate with each other).

Here, client is typically the part of the application that is executing on the user's computer, which the user is interacting with. Server is defined as the part of the application that user is not interacting directly, and is not on his computer but somewhere else. This separation can be for any of a number of reasons: data size, data security, data availability, or simply coordination.

For example, when you go to Google on your web browser, the web browser is a client. Google is the server. Your computer does not know where everything on the Web is; but Google has a pretty good idea.

For another example, if you play MMORPGs like World of Warcraft, your game is the client, and Blizzard's computers are the server; you tell the server what you are doing, and the server tells you the results, just like a pen-and-paper gamemaster. Without the server, you couldn't know what everyone else is doing.

Or, if you want to consult the atomic clock at the U.S. Naval Observatory, again, you are the client, the clock is the server; you contact it because, obviously, you don't know the correct time, and it does.

Now, for example, you might say that server might not be needed in some cases. For example, in the MMORPG case, couldn't the players contact each other directly? The first problem is discoverability: how would they find each other on the Internet? There has to be some central location to tell everyone everyone else's address. But if that is all the server did, you would have to contact all of the online players (and there are a lot of them) to ask them where they are, and if they are on the same map ask them the same question very very often; your internet connection would not be able to do it. There is also security to consider: a server makes sure (or should make sure) that you are not teleporting around on the map by changing the game's code and telling other player bogus values. For example, if client was responsible for remembering how much gold a player has, it would be trivial to become very rich very quickly: just lie about it to others.

Client-side logic OR Server-side logic?

In many cases, I'm afraid the best answer is both.

As Ricebowl stated, never trust the client. However, I feel that it's almost always a problem if you do trust the client. If your application is worth writing, it's worth properly securing. If anyone can break it by writing their own client and passing data you don't expect, that's a bad thing. For that reason, you need to validate on the server.

Unfortunately if you validate everything on the server, that often leaves the user with a poor user experience. They may fill out a form only to find that a number of things they entered are incorrect. This may have worked for "Internet 1.0", but people's expectations are higher on today's Internet.

This potentially leaves you writing quite a bit of redundant code, and maintaining it in two or more places (some of the definitions such as maximum lengths also need to be maintained in the data tier). For reasonably large applications, I tend to solve this issue using code generation. Personally I use a UML modeling tool (Sparx System's Enterprise Architect) to model the "input rules" of the system, then make use of partial classes (I'm usually working in .NET) to code generate the validation logic. You can achieve a similar thing by coding your rules in a format such as XML and deriving a number of checks from that XML file (input length, input mask, etc.) on both the client and server tier.

Probably not what you wanted to hear, but if you want to do it right, you need to enforce rules on both tiers.

Server side processing or client side processing?

Well first of all thats a very nice question.

it completely depends on the volume and transactions your site handles and if you really want your application to scale, i wish you do it right! and do it right from the beginning.

Stop putting your business logic on the client side
** dont expect to eat end user network bandwidth when he makes a comparison call :) and dont expect he has the best bandwidth.

Load balance your server farm
make sure your server farm is properly load balanced and the comparison is done using multi threads instead in a single thread

cache results
** if you are doing this on the server side, if user a and user b asks for the same comparison you can actually pull it from the cache for user b instead doing these requests again.

Usability
show the progress of comparison to user instead showing a loading spinning image :)

hope it helps

Client-side or server-side framework?

I'd say - depends whether you want to be more frontend guy or backend guy in future. If you want to be full stack developer then it doesn't apply.

In my opinion, both Symfony/Zend or other big server-side frameworks aren't so exciting as dynamic frontend JavaScript frameworks like Ember/Angular/React.

Also, if you have already RESTful API and OAuth authentication implemented in backend part I'd go with Ember. Why? Ember Data is great tool for talking to backend API. It's mature, it lazily loads records when they're needed and it's very customizable.

it's fully instantiated in the browser,so the user can change
absolutely all code and data I provide...

Ember has built in security like sanitizing data which is rendered in it's templating language - HTMLBars. Also, there's CORS and content security policy (CSP) standard which is implemented in Ember.

I want to be absolutely sure of the technology that I use in case I
make this application available to the public for example. I want to
do things properly, in order to avoid maintainability or security
problems .

In Ember you can create mature, secure, production-ready applications, but you need to comfortable with your Ember skills to some degree to build such ambitious web application, but it's part of building every application.

With the things that i already have(webservice / api), is it a good
idea to use a client framework like Angular?

Yes, it's very popular solution to use MEAN stack or go with Ember + RESTful API.

Why should I choose Ember instead of Angular (which have a larger
community/tutorials/answered questions) ?

Angular has larger community/tutorials/answered questions, but when I started some side project with Angular to learn its possible advantages over Ember, I was surprised how there was no consensus in it's community for doing one thing. So, instead of fast search how to declare and use directives (I think it was the thing that confused me) I have to do another research which way is the best. Also, there are lots of ways to setup project (where to put custom directives, different Angular objects) and you have to do another research which one to choose. I ended up using repo healthy-gulp-angular as my template, but you can see it hasn't been updated for 8 months, but I think during these 8 months Angular had a lot of changes and I'm not sure if this repo is the best choice.

In Ember you have Ember CLI tool which is built with Convention over Configuration principle. You have also Ember Data which utilizes JSON API standard - if you don't have JSON API compliant server side right now, you can write custom adapter to normalize server responses or change how backend replies. In Ember you don't have all that headache and different best solutions to do 1 basic thing depending who you ask.

What means "Single page application" ?

Single-page application is basically a page which doesn't have to reload all assets and HTML when you navigate. It's advantage over PHP - when user moves to another location he downloads only new data for that route. More info here.

Does those frameworks allow me to create real routes ? (
www.myapp/profil/userid etc )

Yes, of course. You don't even need # in your URL. With simple rewrite rule and small amount of logic for profile route and specified path profile/:userid, when user will open URL www.myapp/profile/userid he will be automatically taken to profile route, and userid would be interpreted as route parameter, so you can take this userid and find user record from the store in model hook.

Client-side processing vs server-side processing , which is fast?

Downloading the JavaScript upfront is usually quicker as a server round trip isn't required (and it is networking operations that are usually the most time consuming).

That said, there should always be a server side solution for any essential functionality (as JS support is not guaranteed), and performance shouldn't be the first thing you think about (trust should be, e.g. you can't trust client side code to make certain that data isn't going to trash your database).

---

Related Topics