Current problems with template engines and a possible solution to them
How many times, as a web developer, did you have the problem of maintaining or implementing html templates?
If you ever used template engine you'd probably know that this is a one way job. Once you have translated your htmls into templates, it is really hard to maintain them.
Most of the times the front end developer or designer doesn't know your template engine syntax, so you end up maintaining the templates. When he changes something to his htmls you must also update your templates.
Not only is the same work done twice, but most of the times the update process is not trivial because you sliced up your templates to reuse common parts like header, footer, navigation etc.
Sometimes, you must even refactor some parts of the html and then css breaks up and you must have a different refactored css, that you also end up maintaining.
Soon you will be losing lots of time maintaining the website layout and become less productive.
But why do this problems appear? This a direct consequence of the fact that you altered the original htmls.
Think for a minute what if the htmls are left untouched in the hole process and you can always send them back to the designer when a change is needed?
The problem just disappears. There is only one maintainer and a more efficient one, because most of the times the front end developer has more html and css experience and can make the changes faster.
Htmls are no longer your problem, you can go back and enjoy writing your code.I had this problem for so long that I said to myself there must be a way of getting away from maintaining all this boiler plate code that ends up eating my precious time and gives me headaches.
I searched up solutions but nothing was easy to use. I found some things like DOM manipulation of the html from the server side code but even if this solves the problem and leaves the html untouched had other two big problems.
One of them was that this was slow, very slow once you start doing lots of complex transformations and sometimes this matters. The other one was that it moves all the boiler plate code that does these transformations code right into your scripts.
And the code was also verbose and hard to use. You must find elements, iterate over them, apply transformations and this becomes so tedious that you just want your template engine back.
So, I got rid of the first problem of maintaining html, but I got another one, big verbose boiler plate code that is also hard to maintain.
So what is the problem with html, it seems that it doesn't fit anywhere, if you take it out of your templates and put the logic in your scripts they will devour them and eat all your time and nerves.
The problem with html dom transformation is that the business logic does not need to interfere with presentation logic. If you do this mistake you will suffer when your application grows and you must maintain it.
The other problem is that html is a declarative language that represents the semantics of the page. When you add imperative template engine code you turn it into a mess, is like you try to mix two different worlds into one.
You probably heard of the great benefits of separating the business logic from presentation logic and the first thing you did was to take out embedded html from your scripts and put it in your templates.
You saw that it made your life easier and you said, that was it, I solved the problem of separating this different logic.
But you only took out embed html of your scripts. That was a nightmare to maintain and you put it somewhere else, making your life easier.
And now your presentation logic is sinked into a fat of html and you must maintain it, is easier to have html instead of complex business logic but still hard.
But this is wrong, your presentation logic must not be in your html, when you need to change one you must also change the other one. This highly coupled approach is the enemy of flexibility and maintainability.
Q:But where to put my presentation logic?
Short answer: keep it separate.
Like you separated your business logic from presentation logic you must also make another separation to make your application truly decoupled and maintainable.
Just think about how hard is to maintain a html with inline styles, and how elegant and maintainable your styles are when using css. Wouldn't be wonderful if something like css would exist instead of template engines?
Luckily for me, such a thing will be available very soon because I'm working on it, it's called cascade html template sheet (CHTS) and is very similar with CSS.
You can check a draft presentation of the language (DSL) here What cascading html template sheet is
Share this with the world
Related
Comments
No comments at this timeMake yourself heard