Providing server level javascript. Good or bad idea?

Question

Now the wiki community!

First I want to clarify . This is not a question in relation to server-side Javascript or a Javascript server. It's about providing Javascript code (which will be executed on the client side) from server-side code.

Having said that, look at the ASP.net code below, for example:

hlRemoveCategory.Attributes.Add("onclick", "return confirm('Are you sure you want to delete this?');") 

This prescribes a server-side onclick client event.

As opposed to writing client-side Javascript:

 $('a[rel=remove]').bind('click', function(event) { return confirm('Are you sure you want to delete this?'); } 

Now the question I want to ask is . What are the benefits of javascript rendering from server side code? Or vice versa?

I personally prefer the second way to connect client-side user interface / behavior to HTML elements for the following reasons:

• The server side does what it ever needs, including data validation, event delegation, etc .; and
• What the server side sees as an event is not necessarily the same process on the client side. those. there are more events on the client side (just look at user events); and
• What happens on the client side and on the server side during the event can be completely irrelevant and unleashed; and
• What happens on the client side, happens on the client side, there is no need to know the server. The server should process and run what they are given, how the process comes to life, and not decide for them in the event of events on the client side; etc. etc.

These are my thoughts, obviously . I want to know what others are thinking, and if there were any discussions on this topic.

Topics branching from this argument can reach:

• Code management: is it easier to display everything from the server side?
• Separation of concern: is it easier to split client logic into server-side logic?
• Efficiency: which is more efficient both in terms of coding and with launch?

At the end of the day , I try to move my team to move on to the second approach. This team has a lot of old guys who are afraid of this change. I just want to convince them of the right facts and statistics.

Let me know your thoughts.

UPDATE1: It seems that all of us who participated in this post have a common idea; It’s good to know that there are others who think alike. Now, to convince the guys;) Thanks to everyone.

Answer 1

Your second example is far superior to the first example. Javascript is your level of behavior and should be separated from semantic markup (content) and CSS (presentation). There are several reasons why this is better:

• Encourages progressive improvement. As you mentioned, the backend code should work correctly in the absence of JS. You cannot rely on your customers with JS. This way you create it once without JS, and then you can improve your experience with JS (for example, by adding client validation as well as server-side validation so that the client can get instant feedback).
• Clean markup. Normally reduced download size. One reusable selector in a separate JS file that can be cached and shared between pages and a handler for each element.
• All your JSs in one reusable place. for example, if your code opened a pop-up window and you decided to resize the window that you would change once in the code in the JS file, instead of changing it on each separate built-in handler.

There are many other arguments and reasons, but they should start you ...

In addition, it can be seen from your example that you have a normal link in the document that can remove content. It will also be bad practice. Anything that removes or updates content should be executed in a POST request (not GET). Therefore, this should be the result of submitting the form. Otherwise, for example. googlebot can accidentally delete all your content by simply scanning your page (and search engine robots do not execute JS, so your warning will not help there)

Answer 2

Biggest differences that I can imagine:

• you will lose client-side caching that you would get if javascript were in a separate js file
• If you need to change your javascript, you need to recompile (extrapolate it to what happens after you release your product: if you need to recompile, you need to redistribute the binaries instead of the modified js file)
• it is easier to use the VS debugger if javascript is in a separate file; you can just set a breakpoint in this file, if you create the server side of the code, then you need to use the function of working documents, find the generated code and then add a breakpoint, and this breakpoint should be added manually each time you re-continue your attachment. As a result, if the code is in a separate file, you can simply configure your code for javascript, F5 code on your browser page and continue debugging without having to stop and restart the debugger.

It should be mentioned that sometimes you need to insert js code from the server - for example, if the main part of your code is in a separate js file, and you need to insert control identifiers on the page for this code to work with, just try to avoid this situation if it perhaps.

Answer 3

It looks like you already know what to do. Putting it on the server side is a bad idea.

The simple argument is that you Javascript lives both on the server side and in separate Javascript files (assuming you use Javascript at all). This can be a nightmare for debugging in order to fix a situation where everything is everywhere.

Unless you use any other Javascript other than server-side scripting, this will probably be fine and manageable (forget that unobtrusive movement says).

Secondly, if you have 100 links per page, you will repeat the same code in 100 places. Repetition is yet another maintenance and debugging nightmare. You can process all links on all pages with one event handler and one attribute. It does not even need a second thought.

<Rant>

It’s not easy to separate HTML and Javascript and even CSS, especially if you want to improve AJAX or UI. In order to have a complete separation, we would have to switch to a desktop application model, where program code with an interface will be generated on the client side programmatically using Javascript, and all interaction with the server is limited to pure data exchange.

Most upstream messages (client to server) are already just data exchange, but not downlink communications. Many server-side scripts generate HTML, combine it with data, and twirl it back. This is great as long as the server remains on the team for generating HTML views. But when the fantasy Javascript comes on board and starts adding rows to the tables, and the div for comments, replicating the existing HTML structure, then we created two points at which the markup is generated.

 $(".comments").append($("<div>", { "id": "123", "class": "comment", "html": "I would argue this is still bad practice..." })); 

This may not be such a big nightmare (depending on scale), but it can be a serious problem. Now, if we change the structure of comments, the change should be done in two places - the server side of the script and the templates from which the source content is created, and the Javascript side, which dynamically adds comments after the page loads.

The second example is applications using drag and drag. If you can drag the div around the page, they will need to be removed from the normal page flow and positioned absolutely or relatively with the exact coordinates. Now, since we cannot pre-create classes for all possible coordinates (and it would be foolish to try), we basically introduce styles directly in the element. Our HTML code is as follows:

<div style="position: absolute; top: 100px; left: 250px;">..</div>

We ruined our beautiful semantic pages, but it had to be done.

</Rant>

The semantic and behavioral separation to the side, I would say, basically comes down to repetition. Do you repeat the code unnecessarily. Several levels process the same logic. Is it possible to drag all this into one layer or reduce all repetitions.

Answer 4

You and other people who answered this question have already indicated the reasons why it is better not to have code on the server side, to insert the internal attributes of events in documents.

The reflective side of the coin is that it is quick and easy (at least in the short term).

IMO, this does not come close to outweighing the disadvantages of the approach, but this is the reason.

Answer 5

For the code in your example, this is not a big deal. The code does not use any information available only on the server side, so it is just as easy to bind the event to the client code.

Sometimes you want to use some information available on the server side to decide whether to add an event or not, or create code for the event, for example:

 if (categoryCanBeDeleted) { hlRemoveCategory.Attributes.Add( "onclick", "return confirm('Are you sure you want to delete the " + categoryType + "?');" ); } 

If you do this on the client side, you need to somehow put this information on the page so that the client code also has access to it.