This might merit a more thorough treatment later, but I wanted to bring a conversation that's started at the tail of a very long comment thread about the prospect of moving to the Twig templating engine in Drupal 8, and what that could mean for front-end developers writing apps with JS frameworks like Backbone.
The short story is: if core templates can do their best to stick within the subset of Twig that has been implemented in JavaScript Twig implementations like Twig.js, we would be able to elegantly build gracefully degrading, easily maintained web apps in Drupal 8.
To give an overview of how this would look, consider two scenarios:
- JavaScript Disabled/No Web App: Twig is rendered server-side, served normally, with standard links, etc. Subsequent calls are standard HTTP page requests (or AJAX).
- JavaScript Enabled and Web App on page: Twig is rendered server-side, templates are provided to the web app code (likely via Require.js or similar loader, aggregated on production, of course), with bootstrap data provided in JSON. Web app then either decorates existing content, or re-renders into specified container div, attaching JS event listeners to intercept all link clicks, etc. defined within controller. Subsequent calls made via JSON API.
This is a pretty awesome framework: there are no duplicate templates to maintain, we get both dumb-client rendered pages and smart-client interactivity, and we get the full power of Drupal translation, etc. in the templates before they are served to the client app.
I think the only thing that would be required outside the WSCCI work and the Backbone module would be an attempt by core theme writers to limit to basic Twig syntax (where there is not a JS implementation, Backbone module or a Twig.js module could override template files/functions).
What do others think about such an architecture? Any other important aspects we should figure in?
Comments
Client side templating is
Client side templating is hugely important and I'm glad you are highlighting it here. The end goal IMO is BigPipe. Bigpipe is a page generation strategy described first by Facebook at http://www.facebook.com/note.php?note_id=389414033919.
JS Prior Art
@Moshe: that pretty much sums it up.
The JS community has a clear leg-up in this one, since the client and server apps are written in the same language. Derby.js and Dev Seed's Bones are two examples of JS-based frameworks with this architecture.
Twig.js compatibility, or something similar, is pretty much the only way I can see Drupal implementing it.
Same Language Isn't Always a Strength
I'm still not convinced that the same language on both the frontend and the backend is a strength. Some languages are just better suited for their specific tasks and worth the learning curve. To take it to an extreme, since you already use SQL on the backend why note use it on the frontend as well?
I'd also argue language agnosticism leads to more robust APIs as you're forced to think from a blackbox perspective. See Steve Yegge's reference to Amazon as an example. http://plus.google.com/112678702228711889851/posts/eVeouesvaVX
That being said I think your idea is a very elegant solution.
templates are only a small part of it
the real benefit of having the same language on both ends, is that the data models and view code is shared.
thus, the code that you use to transform/pipe the values into the templates, and the representation of the objects .. meaning stuff like validation and so forth works.
If you dont have this, you have a significant amount of code you need to duplicate in 2 different languages, and it's almost a certainly that you will introduce a lot of painful issues when the implementations dont match.
the other really REALLY REALLY complex part in this, that nobody has really nailed, and Drupal (php really) is probably incapable of solving with this, is shared state.
Each browser tab on the site has the site running with whatever state is running. PHP/Drupal only works on a request basis, so it needs to rebuild that state for each request. This is a constant source of strange, difficult to debug behavior.
It's a nice idea, but imo trying to make this in drupal is going to be more pain than it could be worth.
Question about "Shared State" Case
Hi Adrian, thanks for those good points.
Can you say a bit more about the shared state/request-based architecture issue, as you see it? What would be an example scenario in which it might cause issues?
I'm generally thinking about all this in terms of Backbone or another client-side framework, in which case the browser state may be composed of many different requests to the server. I suppose I'm a bit unclear which state would need to be "rebuilt" on each request, since an app like this can be built in fairly strict REST fashion, with state driven by hypermedia and the API protocol. Which situations are you thinking about, mainly?
Agree with Adrian
I have to agree with Adrian. The twig template files are only a small part of the code needed to generate the markup; you still need the raw data and the code to transform that into the variables for the template file.
If we use twig for our JS templates it will be a win, but not a huge win.
- John (JohnAlbin)