3 ms·

I built a variant of this style a couple years back http://code.activestate.com/recipes/440563-yet-another-reinvention-of-a-python-html-generatio/ http://code.a

I built a variant of this style a couple years back http://code.activestate.com/recipes/440563-yet-another-reinvention-of-a-python-html-generatio/ http://code.activestate.com/recipes/440563-yet-another-reinv... . I used it to generate static content in advance, but it could have easily been used for dynamic content. In my experience, when working as the only person on a project (all of the backend and frontend work), reducing context switch time in the form of removing languages can be a benefit. That can be augmented by knowing a templating language well enough (I personally got to that point with Cheetah and Spitfire), but then there is still javascript. Using Python syntax as html syntax is convenient as hell, but it isn't really all that maintainable once you go beyond the basics. When your team moves from one person to multiple people, and you've actually got a frontend person who is really good at some templating language, productivity explodes, as the frontend person will be spending most of their time in that language. Also, you're not going to be finding someone with any experience in this new language you've written. The best new languages are ones that are evolving from previous languages, addressing the weakpoints in the former (django -> jinja, cheetah -> spitfire, etc.). Finally, and this cannot be overstated, the insertion of business logic into templates is the worst cardinal sin of modern web development. Back in the wild-west days of the 90's through around 2002 or so, the use of ColdFusion, PHP, etc., was all understandable: we didn't know any better. But then we started getting usable templating languages in pretty much all programming languages, and they evolved. And the building of application logic into separate layers became not only possible, but became a time saver. Your backend guys build the logic to pass data into the template, your frontend guys format/handle that data into web pages. Business logic is in exactly one place. In the context of this language that you have written, while that isn't necessary, because your html templating is in Python, you will be tempted to introduce business logic into your template. Otherwise, it is nifty :) Welcome to the world of templating.

agentultra 16y ago
I think you're over-emphasizing the importance of the separation of business-logic. Essentially your templates shouldn't be making database calls, sure. But just because your template language is written in Python doesn't mean your templates are going to be making database calls. If the team is small and everyone knows Python well, I can see a pure-Python template system be far more advantageous than using a template language. Template languages are simply for designers anyway who don't understand Python (and don't need to). Good job on weby! Look forward to seeing the rest of the framework.
- DrJosiah 16y ago
  There is more to business logic than database calls. And there is more to modern web development than your backend language and your templating language (hello javascript, jquery, yui, mootools, etc.). Again, as I stated earlier, reducing the context switch time can help, and this may be low-hanging fruit for very small teams, but almost every Python programmer will be coming into this having used one of the big Python templating languages. And the moment you get a frontend person with usable jquery, yui, mootools, etc., experience, most of this "oh, try this new templating language that isn't like any other templating language you've probably ever used" is going right out the window; they are going to rewrite everything in the language of their choosing (it happened with our guy and django -> jinja, which was the right thing).
steveklabnik 16y ago
> Finally, and this cannot be overstated, the insertion of business logic into templates is the worst cardinal sin of modern web development. Agreed. This is why I started using haml; it makes doing this _possible_, but really, really hard and ugly.

agentultra 16y ago

I think you're over-emphasizing the importance of the separation of business-logic. Essentially your templates shouldn't be making database calls, sure. But just because your template language is written in Python doesn't mean your templates are going to be making database calls. If the team is small and everyone knows Python well, I can see a pure-Python template system be far more advantageous than using a template language. Template languages are simply for designers anyway who don't understand Python (and don't need to). Good job on weby! Look forward to seeing the rest of the framework.

DrJosiah 16y ago
There is more to business logic than database calls. And there is more to modern web development than your backend language and your templating language (hello javascript, jquery, yui, mootools, etc.). Again, as I stated earlier, reducing the context switch time can help, and this may be low-hanging fruit for very small teams, but almost every Python programmer will be coming into this having used one of the big Python templating languages. And the moment you get a frontend person with usable jquery, yui, mootools, etc., experience, most of this "oh, try this new templating language that isn't like any other templating language you've probably ever used" is going right out the window; they are going to rewrite everything in the language of their choosing (it happened with our guy and django -> jinja, which was the right thing).

steveklabnik 16y ago

> Finally, and this cannot be overstated, the insertion of business logic into templates is the worst cardinal sin of modern web development. Agreed. This is why I started using haml; it makes doing this _possible_, but really, really hard and ugly.