When are scripts inside HTML not considered a bad practice?

Question

I am new to web development. While studying the Play framework and JSP, I noticed that they both give an option to place script (in jsp scriptlet) inside HTML, but in both books I am reading they both say it is bad practice and don't give an explanation as to when should I use scripts, only writing not to.

My question is, if both frameworks supply such an option, when would it be ok to use scripts inside HTML?

Please note, I'm talking about server side scripts for creating dynamic HTML (i.e. JSP scriptlet).

Answer 1

There are mostly two reasons to put scripts outside HTML code:

1. Server-side, separation of concerns and clean code. You quickly understand why you must be very careful with that when you see some PHP code which, in the same piece of code, mixes PHP, SQL queries, JavaScript, HTML, CSS and Base64-encoded images embedded in CSS.

2. Client-side, external scripts are easily cached. If your HTML is a dynamic page, it may change often. By putting scripts outside HTML, you allow your visitors to download this content once, and never refresh it again (well, not never, but rarely). In the same way, if two static or dynamic HTML pages share the same script, putting it in an external file will allow to download it once.

▪ The first point is valid in all cases. You'll never be able to justify that it's cleaner to mix everything in one file. Why frameworks allow this? Because there are situations where you don't care about clean code:

• If I write a small page I'll throw away for sure, and I must do it quickly, it's not so bad to put everything in one file.

• If I want to show a short example to my colleague (by putting a single file to a document management system platform) or publish it to a blog¹, having everything in one file can be acceptable and useful too.

• If I must create a small prototype before developing the application for a customer, best practices don't matter at all, while reducing cost is critical for source code which will be thrown in all cases.

▪ The second point, on the other hand, explains why there are perfectly valid cases to put scripts in HTML:

• The script changes on every change of a dynamic page. In this case, why would you force the client to download the HTML file, then the separate file containing the script (i.e. doing two requests, which is a waste of time and resources which must not be neglected for the websites of some scale), while you can provide the same thing through one request?

• The static HTML page uses the script which is not shared by any other page of the website. It's a perfect candidate too, if you want to avoid doing two requests².

Now, returning to the first problem (clean code), you can serve scripts in HTML and have clean code server-side (for example by using a template which will inject, at runtime, the script which is written separately). This, of course, requires some level of expertise, and as I said before, combining scripts and HTML is needed only on high-scale websites. This means that if you're seeing an inexperienced developer mixing scripts and HTML when doing a personal website, it's a good sign that something is wrong.

---

^{¹ Personally, I'm against this practice. More we share through our blogs code which does not follow best practices, more the less experienced developers would be encouraged to copy it and to believe that this is the right style.}

^{² With appropriate caching configuration, two requests will happen only for users with empty cache. For others, you can set the expiration date for the far future, and the browser will avoid the request which will return the 304 Not Modified response.}

Answer 2

I can think of several places where I would do this

1) Simple testing of an idea, I want to see how something works and don't intend to keep the code.

2) Data initialization, where the actual program logic is in an external file but I want to load initial data for some reason and don't want to have an ajax call to get it. For example if I have a list of countries that I will need to use that would be a perfect candidate. It will change rarely and can be inserted into the HTML page by way of whatever language I am using server side (PHP, Ruby, Haskell etc), in this case I may have some code like this

Data.countries = <?php echo json_encode($countries); ?>;

Answer 3

Never. Mixing the presentation and business logic is a bad strategy for long term maintenance. You should avoid it, and will eventually come to regret it in almost every case.

What changed is that the problems with that approach were noticed, and the world has generally moved to better, more robust solutions - but the Java folks care deeply about long term compatibility, so they keep this feature around in case it would make life more miserable for someone who depended on it.

Answer 4

Tools are sometimes supplied in such a way that they can be misused. For instance - you shouldn't put your shoes on backwards even though "technically" it's possible. At first it might be cool, or if you're lazy it might save you some time, but down the road it will hurt you ... and the shoes ... think of the shoes!

Scripting inside web applications is a very common practice. But it does not lend itself to maintainable code or "future proof" code.

Some golden rules are keep the logic, view and data all separate. When properly thought out - you should never need to actually script anything.

Down the road when you want to do unit testing...but your views contain logic...you will be kicking yourself after you realize you cannot make simple, common sense assertions.

Also - if someone looks inside a controller and expects to find logic and it's not there - they will be cursing your name when they have to hunt around the application for where you decided to stick it.

Scripting methods lend themselves to obfuscation and duplication.

-> You can play with it yourself in your spare time, do some projects from scratch and revisit them in a month.

-> You can learn the hard way and use scripting methods regardless of what others say.

-> You can save yourself some valuable time and focus on proper application architecture and design.

Remember, the web development industry is littered with the corpses of developers who refused to learn from people who had to mud through the trenches and save themselves some time and agony.