Ugh, Jinja is not an "excellent" templating language. It's a terrible broken mix of pythonisms and arbitrary-feeling restrictions and oddly missing pieces. It becomes hard to read very quickly and some of the looping idioms are just nuts. Sorry I don't have anything constructive to say here but I'm genuinely taken aback that there are apparently big fans of Jinja.
I was wondering if we should not code a Python renderer for one JS framework and be done with it.<p>We already have one JS engine in Python (<a href="https://github.com/kovidgoyal/dukpy" rel="nofollow">https://github.com/kovidgoyal/dukpy</a>). We even have pluggable renderers (<a href="https://pypi.python.org/pypi/PyExecJS" rel="nofollow">https://pypi.python.org/pypi/PyExecJS</a>). Later we will have webassembly renderers in Python, so you will be able to take frontend frameworks, compile them and execute them in Python.<p>Finally, we have some fantastic framework that are powerful, yet not that big, such as Vue.js, that already have a pluggable architecture for rendering without a DOM on the server side (<a href="https://ssr.vuejs.org/en/basic.html" rel="nofollow">https://ssr.vuejs.org/en/basic.html</a>)<p>The Python community has done much more complicated projects already, and half the work is there, so my guess the reason it hasn't happened yet is we REALLY hate js and most of us just touch it to get the job done and go to the next task.<p>It's a bit like the async situation. We have the tools, but there is no Django of the asyncio because we love our tools as their are so much. I'm so guilty of this.<p>The problem is: the rest of the Web is moving ahead, and while it's still relevant to do DRF + Vue.JS right now, one day stuff like meteorjs will be so crazy yet stable it will be hard to compete.<p>I was hopping webassembly would let us eventually run Python on the client side. But I doubt it will happen. However, I'm thinking more and more than it will allow JS tooling to be plugged in many other languages on the server side.
"Isomorphic" templates are not enough. You also need isomorphic data fetching for client code. If you have to manually reinvent the same data fetching on the client and server, you don't get the full benefits of isomorphic code. You only have brittle templates with two different ways to glue data to view.<p>So far isomorphic Node + React has been the best (but not perfect) way I've seen to do this. You abstract out the API layer, and now you can define components and their data sources that have the exact same code on the client and server, and it just works. Apollo/GraphQL is probably a giant leap forward in this as well.<p>Having an option to do hand-glued "isomorphic" data in a few places is probably nicer than Javascript spaghetti on the front end, but it doesn't get you all the way there. Rails has the same problem by the way, the "Rails way" is coffeescript glue to get any kind of modern front end application functionality. Even with React on Rails you have to have to reinvent data fetching, and lose the benefit of a well structured isomorphic codebase.<p>Until browsers support a different language natively other than Javascript (which will never happen), Node + React is currently the most straightforward path to get there.
I've done this many years ago with <a href="https://github.com/wkral/jinja2js" rel="nofollow">https://github.com/wkral/jinja2js</a><p>It works - but there are gotchas:<p>1. You can't depend on useful pythonisms/javascriptisms such as<p><pre><code> {{thing or ""}} vs {{thing || ""}
</code></pre>
2. Template filter code still has to be duplicated in both languages - i18n such as {{_('String')}} for example - which sort of makes sense - but then you have to do the same for some other, really trivial, filters.<p>3. Testing becomes annoying because a template can work in one, and not the other - you have to test both.<p>4. You don't get the newer html diff style virtual dom rendering which can cause issues with stuff like select boxes. You end up with special case code to handle that, which is more of a hassle.<p>The conclusions from it all were:<p>a) You <i>do</i> save time over doing it once in python, once in js<p>b) You <i>don't</i> save time over doing it all in js - especially if you use a newer functional style js template framework (react/vue/polymer)<p>c) You can still get the best of both worlds by hooking up your templates in js to be rendered by your backend - eg like <a href="https://github.com/reactjs/react-rails" rel="nofollow">https://github.com/reactjs/react-rails</a> does.<p>In the end for my next project I decided to do an api for the backend in python and the website/frontend in react with SSR, and am really thrilled with the results - very maintainable, testable and simple overall.
I see a few problems.<p>The biggest problem is testability. Testing that a template renders correctly means parsing the markup into a DOM and asserting that certain conditions are met. This is exacerbated by the differences between Jinja and Nunjucks, which can be non-trivial and unexpected (e.g., Jinja will render synchronously, while Nunjucks can render asynchronously--weird async behavior may appear). Since your application doesn't have the same entry point to the code (they're in two different languages!), you really need to write two different sets of tests for the same template to get proper coverage. Templates being templates, you also don't get the granular testability of a React component out-of-the-box, which can be pulled out and tested individually.<p>Templates alone also don't include anything in the way of handling events, component lifecycle, and other things that make your code actually do stuff. You'll need to bind event listeners manually, and those will of course need their own separate tests.<p>Making Jinja useful also usually involves adding your own plugins and filters. This happens in Python, which means you'll need to write all of those a second time in JavaScript, and test them. Doing this right means comparing the output of the two versions, which isn't necessarily straightforward. Given the complexity of this, I wouldn't bet money that other engineers would go through the hassle of making sure this is done correctly.<p>I'd encourage the author to write more about the pitfalls of this approach. It's easy to write {{ foo.strip() }} in Jinja and forget that Nunjucks requires {{ foo.trim() }}, or empty arrays being falsey in Jinja and truthy in Nunjucks.
Mike Bayer wrote a really interesting article about this topic 5 years ago: <a href="http://techspot.zzzeek.org/category/mako/" rel="nofollow">http://techspot.zzzeek.org/category/mako/</a><p>These techniques are easier with the Pyramid framework.
I usually ignore server side rendering or isomorphic rendering. I'm not saying all projects should ignore it but you're really talking about a high level of optimization if you need it. And if you're reaching that level of optimization you probably shouldn't use Python.<p>Server side rendering only makes the first view faster. After that, everything is rendered on the client and faster that way. And if you use caching with progressive web apps or just file caching in general, the first view will be fast after. So you're only optimizing for the first of the first. You can then provide the initial data in the page request so that saves a round trip on the first request while still rendering on the frontend.<p>I say all this to just point out that there are many ways to speed up your frontend without doing SSR and they are much easier to implement with Python. So I'd rather exhaust all these techniques before implementing SSR. If I get to that point though, I suspect Python might be the slowest part of your stack. And lastly if you are doing SSR for SEO purposes then just use a prebuilt prerender service.<p>With all that said if there was an easier way to SSR with Python/Django, I'd definitely use it. But Jinja on the frontend doesn't sound like that answer.
Would not recommend using Nunjucks, unless you would like to contribute to maintaining it.<p><a href="https://github.com/mozilla/nunjucks/blob/master/CONTRIBUTING.md" rel="nofollow">https://github.com/mozilla/nunjucks/blob/master/CONTRIBUTING...</a>
I actually wrote a JavaScript code generator for Jinja, which allows you to use the Jinja parser and AST and generate pretty readable and fairly sane JavaScript code (for a pretty large subset of full Jinja). I actually used this in my startup (now long dead) where we were able to reuse quite a lot of template code both on the server and the client.<p><a href="https://github.com/djc/jasinja" rel="nofollow">https://github.com/djc/jasinja</a><p>This is in some (conceptual/experiential) ways a precursor to my recent attempt to create a Rusty Jinja-like, which tries hard to take the best ideas from Jinja and mash it up with the best ideas from Rust:<p><a href="https://github.com/djc/askama" rel="nofollow">https://github.com/djc/askama</a>
The post reads somewhat rambly, which I suppose is unavoidable if you're doing a quick whistle-stop of a bunch of related technologies showcasing a new idea.<p>The only thing that doesn't seem clear is why you'd need to combine server- and client-side rendering in a single instance. Jinja is an incredibly useful and well-made tool, and my experience of it with Flask always leaves me with the best impressions of it being exactly what quick webdev should be, but why would you combine it with JS? Surely the use cases are so different that a separate JS library would be just as applicable, and perhaps more fit for purpose.
Templates cause bugs. The solitary appropriate solution is an unparser – a component that walks an AST and serializes it.<p>Making sure the result conforms to the grammar of the output language without any unparser would always involve a parser.<p>> As soon as I'm looking at more than one programming or markup language in the same file, I'm looking at spaghetti code.<p>Iain Dooley, December 2011<p><a href="http://www.workingsoftware.com.au/page/Your_templating_engine_sucks_and_everything_you_have_ever_written_is_spaghetti_code_yes_you" rel="nofollow">http://www.workingsoftware.com.au/page/Your_templating_engin...</a>
I've been working on a site recently, in Rails, and just been using Turbolinks and SJR (Server Javascript Responses). Granted, it's a content heavy site with fairly light ajax interactions, but it's a pretty delightful process.<p>So many people jump to heavy JS libs/frameworks to do stuff that can be solved in much more boring/simple ways most of the time. You don't need React/Angular/Vue to submit a form over ajax.
Ugh. After living in frontend land (native mobile and react) I'm really not looking forward to going back to Django.<p>It feels so irrelevant in the world of backend-as-a-service and GraphQL.<p>...Please forgive my cynicism. I am looking for a reason to like this. Maybe I should just move on.
I don't understand people still using Django for their web based stuff. I was under the impression that ReactJS + aiohttp was state of the art. Please explain why I am wrong.
Can someone explain to me why we haven't normalized html templating with a Pug-like syntax (formally Jade)?<p>My perceived benefits of Pug/Jade:<p>* Significantly fewer LOC<p>* Improved Readability<p>* A lot of existing tooling thanks to its popularity in the NodeJS community