Reddit 1.0 source code

>I still don't get why non-code templating ever became popular.

Because if you're working on a team, not everyone on your team may be a programmer, particularly if they're just working on layout design, and the problem that templates solve in that regard don't require complete access to raw code. Separating one from the other makes it easy to focus on one versus the other. Just look at how messy a complex Wordpress template can get and how difficult it can be, just reading it, to get a grasp of what the HTML would look like, versus a Twig template which has a lot less noise.

>Especially that I saw it becoming popular in PHP, which itself is a better templating language than the templating languages people were using.

I've been down the road with PHP where everyone working on javascript and CSS also had to know just enough PHP not to break the site, because everything had raw PHP mixed into it, and then somewhere in the vast tree of includes including includes someone forgot to manually escape a variable that came from the database, or else they did, but now someone else escaped it twice, or they created some weird encoding problem because they were in a javascript context.

PHP is at best an adequate templating language, and a good base to build a sane framework on. But a framework is necessary beyond a certain level of complexity, because most projects benefit from features that raw PHP doesn't provide, such as context-aware and automatic variable escaping, template inheritance, template caching, etc. You will either wind up using an existing templating framework, or you will wind up implementing an ad-hoc, informally-specified, bug-ridden, slow implementation of an existing framework.

>That said, glue-strings-together templates are still a problem and should not be used. HTML document is semantically a tree, and if you don't treat it like that, bugs and security vulnerabilities follow.

There's no way to get that in PHP without a template framework. PHP, unfortunately, doesn't even know that HTML exists[0], despite having the sole purpose of being an HTML preprocessor.

[0]I just remembered there are XML functions like DomDocument that can be used to process HTML (with... effort) but I don't know whether or not you could get something like XHR out of it, and by extension, avoid the problem of HTML as concatenated strings.

Wow. Offended much? Did I say (or even imply) I had one? All I did was provide a counter to the claim that open source means more eyes which could make your software more secure.

Can you explain what you mean, if it's not one of the things I mentioned (that are often called "templates") and how it doesn't have the drawbacks for a small team that I mentioned?

I went to Bletchley Park a couple of years ago. It's a very fascinating place. I remember hearing stories of code breakers who could infer that a piece of plaintext was all JJJJJJJJJJJ simply because, upon looking at the ciophertext, it contained no J (relying on the fact that no letter would ever encrypt to itself in Engima, because of the reflector). Indeed the Poles don't get enough credit for their contributions. And yeah, virtually all encryption was similar to Engima back then: the Allies too had a similar machine. I believe traitors sold secrets or Engimas were captures on U-boats and so on, so security through obscurity wasn't really a thing back then either.

The origin of that statement (Kerckhoff's principle) refers to cryptography, not to application security.

If you take a quantitative, cost-based approach to modeling security through adversarial capability, obscurity becomes a perfectly valid security measure if it's not used in isolation. We don't use it for cryptography because the tradeoffs aren't worth it. It's better to design cryptography with provable security based on mathematically rigorous computational hardness assumptions than it is to make secret algorithms.

In the context of application security, if the decision to obscure some or all of your system incurs a non-trivial cost to an adversary, it makes sense. We can't rigorously and mathematically prove the security of applications in the same way we can prove e.g. an algorithm is sub-exponential instead of polynomial time.

You often see "security through obscurity" mentioned in the same way that people cite "appeal to authority" or "ad hominem" fallacies in internet debates. The reality is more complex than that. Fundamentally, anything that increases the effort required by an adversary to successfully compromise your system is worth considering. You just shouldn't depend on it in its entirety. Closed-source software is a good example of robust security through obscurity, as basically any security engineer will tell you (I'd rather look at source code line by line to find vulnerabilities than try to find them through trial and error in a penetration test).