[mylife] Developer best practices - Too much Client Side scripts

[david_legrand]

Hello world,

I was away from the community for quite some time. Just want to post a little message to all the new developers.

ServiceNow is a great platform (you probably already know that ), extremely agile so you can implement requirements in multiple ways and that's GREAT but the platform agility also requires to understand the platform and to take the best options for performance/scalability/upgradeability.

I have been involved recently as a fireman in a project to fix issues after a complex go live. Probably the project involved some completely new consultants and the architect / senior consultants weren't enough present to guide / help / check / validate the work of these new consultants. I don't blame anyone because I think the customer and the partner should share the responsibility but the project organization failed somehow.

So, on this instance, I was seeing client scripts, like everywhere. Yes, client scripting is simple to understand (specially for new consultants), yes it did work on the development environment where 10 users are connected and yes when you understand one way to perform things, you want to reuse this knowledge again and again.

But it doesn't mean you have to perform everything with client side scripts (client script or UI Policy).

What is the impact on the performance? Please remember that the client script has to be transmitted over the network to the user browser and is executed on the browser... So unless if you are linked with a direct fiber channel between the server and your own laptop which has a lot of CPU / RAM, the client side script will always take more time that server side scripts

When to use the client side script? ONLY when the user has to see something changing on the screen before saving and try to challenge the requirements to make most of them "after the user has clicked on save"

For example, you do NOT perform security requirements with Client Scripts. Alright, in 0.0001% of the cases you might but globally if you have the word "restrict" or "security" in the story, you do NOT use client side script.

==> If you do, think of me going on your environment, opening a list layout and bypassing your security rules by double clicking on the cells. And please don't tell me that your answer is to disable the list edition...

Another example, you do NOT use DOM manipulation unless if you really have a good justification and you know why the ServiceNow standard API can't help you. That means the sentence "the API function didn't work" isn't a good justification because you probably already have way too much customization made in a bad approach.

And if you tell me "We don't have the time to debug", I would reply "Ask your customer if he wants to pay 2 hours now OR 2 weeks in 6 months".

ServiceNow has some best practices Client Script Best Practices - ServiceNow and you should have additional best practices in your company (specially if you work for partner companies)

I'll be honest with you guys, I have read some discussions on this community, I really fear for the performance/scalability/upgradeability and the user experience on few of these instances because some people reply "use client side script" to any question.

And I'm concerned because if WE (the developers) do messy work, then the C-Level people will continue to ask for "Out of the Box" implementations and the ServiceNow vision will be completely spoiled...

Conclusion: Client side scripts are really useful in specific cases but use them only for these cases and not as a default way to implement and when you have a doubt, ask the architect or a senior consultant who has to help you. And if you do something wrong the architect / senior consultant has to explain the best practices and to take the decision between asking you to redo, redoing it himself/herself or living with this piece of work

Best regards,

David

[Deepak Ingale1]

Hi David,

1) What is the business requirement for this feature? Does is make sense? (functional point of view).

We have just developed one of the application and about to launch it for UAT. Records of the application are going to be stored in one of the extended table of 'task'.

This task table has around 4L records including incidents, problems, changes etc. So need to check if any UI policies / client scripts / BR   on 'task' table are affecting this new application via inheritance with respect to performance.

3) I agree with you that things like data validation should be left for server side , but many a times customer finds this annoying. You are then left with no option rather than going for client side validation.

4) Hmmm, yes, agree with this as well, most of the developers are not aware with "encodedQuery" feature which might help in complex calculations / condition buildings. Also, how many times you have a person with knowledge of platform and challenging the requirement in requirement gathering call?

I have seen the requirements like "Update" button on the form which is being render via "global" UI action was asked to rename to "Save"?

Example like this is real candidates for challenging requirement, but I have seen that these global UI actions are hidden via DOM manipulation client scripts on table, configuring new UI button with the label "Save".

The mindset of developers is like though it is a customization and if it is possible, we should do it just for the sake of "Customer Satisfaction".

Things becomes difficult if you have to review code built by 10+/-   coders who are new to SN platform also Keeping in mind that your sprint is about to go for testing in next couple of days. That gives very little time for review as well fix.

[Kalaiarasan Pus]

This is a interesting post and a welcome one!

I see a lot of post suggesting client side script too and when you comment to use a Glideajax or a display rule, nobody cares or seem interested to learn the reason why.

About pushing back on certain requirements - Many organization doesn't have this in their culture 'taking no' for certain requirements. The instance health is last of their priority. Sure that bites them back after sometime and but they are okay with it. Some organizations have architects who don't have a clue about ServiceNow. So working with them, is left to your imagination.