Don't Make Convoluted Code Part 2

Client-Server Processes

Now we have enough understanding of the differences between client-side and server-side scripting and the scenario of the entire process with the help of previous part.

Let's explore the real life scenario through an example code where PHP code has messed up with the JavaScript code in a website programming document.

<script type="text/javascript">
    var foo = 'bar';
    <?php
        file_put_contents('foo.txt', ' + foo + ');
    ?>

    var baz = <?php echo 42; ?>;
    alert(baz);
</script>

our hire dedicated programmer team has created and run this test code and unfortunately browser has responded in wired way. It displayed '42' placed into the PHP code, instead of 'bar' put into the JavaScript code.


Let's dissect the code in to two fragments. One is JavaScript code and another is PHP code placed as nested code in JavaScript code. As we know that JavaScript code is falling in to the client-side code category. Whereas PHP code is purely server-side code. I am using word 'purely' as PHP never runs on the client devices at all while JavaScript code may created as the ensue of server-side scripting and server many times send JavaScript code embedding into the HTML documents to get desired results. Therefore, we can't say that JavaScript code is not found on the server. However, server don't need to run JS in most cases and simply generate it or packed with HTML docs.


With this understanding let's see what happened with our example code closely. When we run this code to test, it reaches to the server and run the PHP code first in the server. Once the PHP code execution finishing or PHP scripts end up, server stops the running any code and return the results obtained through PHP code compilations. There are no chances of running JavaScript on the server at all. Moreover, the returning results also missing the original JavaScript code so you only getting the results of PHP code executions in the browsers of the clients.


Therefore, in our example code we don't get any results for the 'foo' variable written in JavaScript. Whereas server run the part of script located in between the <?php...?> tags only and send alert 42 in return. Therefore, only alert call works and foo variable missing at all. However, this was a simple example code, but when you need to pass the variable or any sort of data written in between the JavaScript there is a programming trick.


You have to rely on the Ajax code means you have to call server via Ajax requests for any kind of dynamic data or you have to put data into the source code of the page, if they are static data so it can be processed with JavaScript. The later technique of embedding in to JavaScript is bit complicated and demands adequate knowledge of converting data into the server-side scripting for further processing.


Conclusively, I can say that if you have any ambiguity regarding to the server-side and client-side scripting and their rules of using in practice, you will end up with convoluted code and prove your code a headache for QA team or for the maintenance team in future. Therefore, our hire dedicated developers department take care of such code understanding and best coding practices prevailing in the industry in order to provide quality work to our patrons.

Don't Make Convoluted Code Part 1

Client-Server Interactions

Today we are living in fiercely competitive environment on outsourcing horizon and we need to create products with high quality with least investment of time and resources. All quality software products need standard coding with the best programming practices. If anything goes wrong in code, it may lead to frequent debugging. In other words, it proves waste of time and resources behind non-productive work.

However, best programming skills come with prolonged experiences and thorough understanding of technologies, tools, and techniques. At Lujayn, the team leaders of our hire dedicated programmers departments frequently do complains regarding to the lack of proper understanding of programming in junior web developers. Therefore, they always avoid their participation at critical levels and let them to learn things correctly and in righteous manners.

Among such complains I have sort out one that is surfacing frequently in discussions. Let me translate that in words. It is lack of understanding of differences between client side programming and server side programming. Thus, they tend to mix up the server side code in to client side code and vice verso. This convoluted code trigger unexpected results and some tough to detect bugs in the products at the end of the project. Let me explain this in details.

Understanding of Server-side and Client-side Programming

Understanding Client-Server Terms

When we use the website or web application or a web app on mobiles, we have two parties working behind the display of web interface on your devices. The first one is your device itself and another is web server that communicate with your devices using HTTP protocol or other modern ways/protocols we can say cloud-computing technologies. Let’s stick to the HTTP protocol for ease in understanding.

Technically, server is a single entity, which is located at remote and central place and communicating with the innumerable devices across the world using Internet. Its prime role is to server the web pages or web interfaces of web applications. These web pages or web interfaces are displaying on the various devices with browsers.

These browser enabled devices term as clients, the clients of the server, which are using the services of the server. No doubt, in a broad concept, not all the client devices need browsers to use services and HTTP to communicate, modern web services in particular. For sake of simplicity, we avoid all exceptions and stick with HTTP and browser concepts.

Now, we know about client and server terms with their respective roles. Let’s check what happens at the code level during the client-server communication. At first place, client wants to see the web page in browser to meet its needs on the web. In due course, client sending request for a particular website by typing URL in browser using HTTP protocol.

Processes on the Server

This request is reaching to the server and server begins processing on it. It find out the source code of the requested website in its databases/storage/memory. Server Runs the source code and create an output in form of HTML or other standard forms, which can render on the browsers of the client devices across the world.

In next step, server send the website code to the client device and now client device/its browser, turns it into the human visible web pages on the screen of device. When device render the code sent by server it processes on it

Server-side Scripts

In above scenario, we have seen that server runs the source code on its machines using its own mechanisms/compilers. During this process on server, some code turns into the different forms in output files or omitted from the inclusion in to the output. Therefore, they term as server-side code or programming and PHP, ASP.NET, C++, C#, Java, ROR, Perl, etc. are claiming as server-side scripts/languages in web development industries.

This server-side scripts do following actions on server and triggers outputs accordingly.

• Its first and foremost function is to process the user inputs
• Create pages for clients to display
• Structure or frame the web application
• interact with databases

Processes on the Client

Once user start using client devices, she put some input to process and create a request to send to the respective server. When server in return send the outputs to the client, its process on its and interpret the code and render it in browsers or interfaces, which are human readable. The performance of client depends on that what the code is coming back to the client from the server and what the capacities of the client devices to process it. Due to known constraints of mobile devices, responsive designers and programmers prefer to have more processes on the server, while in case of big sister devices web programmers go leeway.

Client-side Scripts

As we know that server is mainly sending markups and styles in return of the requests made by clients. Therefore, HTML and CSS are main forms of code need to be rendered on the client or browsers. However, server also send JavaScript in some responses along with HTML and CSS. Today other scripts mainly based on JS libraries like jQuery, Media Query, etc. are in use for dynamic and interactive website or web applications for multiple screens.

No doubt, the king is still JavaScript and it always renders on the client devices therefore, it creates great confusions for the newbie developers when they embed the JS code in HTML along with other PHP code. In next part, we will see some practical problems and try to understand the differences between server-side and client-side programming paradigm.

Should We Use Browser as A Web Development Tool

Browsers As A Web Development Tool

Exploring the Internet is not possible without the browsers on any device, be it on desktops or on tiny smartphones. Technically browsers render the code and enable us to view the outcome of our source. Therefore, we initially and still today use browsers as the instruments to view source.

Since the beginning, browsers are performing this basic need of view source by providing enough tools. Just like other technologies on the web sphere, browsers too evolved with the pace of time and now many experts eyeing to make it a web development tool with some amazing capacities. Before discussing on the debate of browsers as a web development tool, let’s check its evolution history.

Evolution of Browser Technologies

As we know browsers have used as an instrument to view source. When we view source along with its rendering results, we simply learn one or two things in our coding and its debugging by experimenting with code and its tools. Therefore, browsers act as a learning tool rather than building tool. Thus, I can say that when we intended to write or test our scripts or markup in browser, we have many limitations.

Technically, when you are going to write code, using JavaScript, you need to have a controlled environment against the inherited run-time environment of the browser. We need these because we have to insert the breakpoints, run and pause code, and test code line-by-line during our writing and testing procedure during web development.

Of course, these are some of the basic functions in web development, but now our advance web development demands more things to do very intricate ways and using highly advanced tools in an established IDE. Therefore, I advocate refraining from browsers to establish as a web development tool. No doubt, Firebug of Mozilla was an evolutionary add-on to offer such intricate debugging capacities to the browsers. Firebug was making writing code easy, debugging JavaScript, inspect DOM, and watching styles applied to the particular node of HTML.

Later on Google has achieved same capabilities in Chrome using its developer tools and begun a new era of offering developer tools in each modern browser. In fact, the craze of developers tools seems somewhat illogical, as we have highly advanced standalone separate IDEs to perform our writing and even testing tasks quickly and accurately. Why we should run behind the browsers like things were challenges are infinite and progress is slow?

Where Are We Heading To

If we want to integrate our run-time testing tools of browsers with the controlled environment of IDEs like tools then we are at right path to incorporate writing and testing tools in the name of developer tools in the browsers. Fortunately, today we have several developer tools such as for DOM inspecting, speed auditors, coding panels, JavaScript consoles, memory profiles, text editors, screenshot takers, color eyedroppers with advance functionality.

Now, question is that should we think of visual CSS editors, accessibility auditors, or an entire FTP/SFTP client in the browsers. What about the size of source code of browsers, their performance, and their basic functionality to render code? Should we send every process to the servers to save clients and their resources? Are we heading towards miniature of browsers in tiny handsets still capable to do entire coding of a website or web application using server resources and cloud technologies?

Do You Have Answers

If you have answers of the some of the questions regarding browsers and their usage in web development let’s have chat on instant messengers of our web development team at Lujayn and PSD to Joomla web designer and web developer teams in particular.

Rhythm in Designing for UX

I think title of the blog may seems odd I am talking about the rhythm and even in the website or mobile app designing. No, definitely it is not wrong at all because I am talking about the rhythm of user experiences.

Rhythm in Design

When our user begins her journey in your design, she should have consistent user experiences. Things must go easy, comfortable, familiar (if not should be guided properly), and quickly. We shouldn't leave any space to think your user more on any step, she should have easy flow with your UIs and should have smooth interactions with your design, layout, etc. These are the things I refer as rhythm in design.

When we talk about the user interfaces in website or mobile app, the subject become wide and out of scope of this blog to cover. Therefore, today I shall talk about only the e-commerce website or mobile app that is offering checkout process because that is the most critical step in e-commerce designing as the highest percentage of shoppers abandon cart on these steps only.

Let's see what we should consider in order to keep the rhythm of our users during checkout process.

Overall Presentation of E-commerce

The journey or our user is beginning with the entry on the landing page, be it home page, product page, or any other page on the e-commerce storefront. Therefore, if you site doesn't have good presentation and consistency throughout all pages or UIs, your visitor will feel break in her rhythm.

Therefore, determine design consistency and user experiences on entire site or app first so you will keep rhythm of browsing intact until your shopper is reaching the checkout process steps after deciding about the purchase of your products. Once your shopper enters on the checkout page or UI, please remove all other clutters, and obstacles from the pages.

User Experiences on Checkout Pages

For instance, recently I have purchased something from a reputed e-commerce site and found unusual difficulties during entire process. Until I reached at the checkout page or stage the overall website experiences were great and on the checkout page I was greeted by friendly UI elements and presentations about the products, their features, and relevant products available on the storefront.

I was pleased to know all these things and after reading all those stuff, I have inserted my card to make purchase and accomplished all signing in process. Oops! At the end I had a slip of statement that was talking about the failure of payment due to time-out.

Placing Obstacles in User Journey

Yes, I lost my valuable time of purchase in reading pleasant, but unnecessary stuff before finishing my credit card sign in process. Now, I have to reinvent the wheel again and pass through all purchasing process, except leaving that distracting reading material. This experiences have taught me to remover clutter and other obstacle from the checkout pages or UI in order to accomplish the buying tasks immediately.

Other experience was with highly crowded user interfaces, inconsistent styles of the UI, and unbalanced compositions of UI elements.

Crowded Interfaces

For instance, on one page, I found tight page grid, small copy that conveys nothing, and lack of enough white space to breath. These things have broken my web browsing rhythm and I left that page immediately. In another case, e-commerce web designer had used red/orange grid lines and some links with same red colors. That had made me to think about something had done wrong in my previous step and I gone back to confirm that.

Unconventional Design

In one more experience, I found form field behaving in non-standard ways and causing shoppers to annoy. In short, if you haven't tested your product frequently and in real conditions with real use cases, you may have committed the sin of breaking the browsing rhythms of your visitors and would lost business in long run.

If you want to save your dream e-commerce designing project from such rhythm breaking experiences contact us by considering us a your dependable partner.