Static site generators.

[Antranig Basman]

Hi Justin -

I don't think I agree with this suggestion, since it seems to me to be based on an over-optimistic view of 
the economies. We will be adopting one of these solutions as a crucial part of our infrastructure, that is, 
as a platform - and therefore investigating their configurability, for a which a good proxy is the ease of 
writing a plugin, is essentially the #1 criterion for adoption. Therefore the costs say, of writing two or 
more plugins, or at the very least, assessing the difficulty of writing a plugin, simply can't be avoided. 
These are costs that we will have to pay as a community sooner or later, and we may as well just try to 
minimise them. We needn't go through the entirety of the exercise of writing a plugin during this initial 
round, but my suggestion is that it is an essential part of the earliest part of the exercise. We should not 
be committing ourselves to a "waterfall" model of evaluating the platforms.

Also, to try to reduce the risks from the "prototype goes into production" route which history suggests can 
never be completely blocked, I'd like to suggest that at the very least any "plugin-free" initial evaluation 
is done with handlebars rather than jade, since its templates at least resemble some kind of markup. All of 
our candidates support this option either out of the box or with an already existing plugin.

Cheers,
Antranig

On 28/01/2014 14:20, Justin Obara wrote:
> Hi Colin,
>
> Just to clarify things. I'm not suggesting that we actually use Jade here on out, just that in terms of evaluating the two static site generators, it has less of an impact. That being said, evaluating the ease of writing plugins is useful, but since they both support template plugins, and that's likely not something we will be doing often, it seemed reasonable to drop this requirement for the evaluation round.
>
> What I would suggest instead is that we aim to collect information on the ease of use and viability of the static site generators and present this along with a recommendation on which one to go with, for the Feb 19th community meeting. This recommendation will come with the caveat that we will need to attempt to write a Weld plugin for it. At which point we can decide as a community if we want to go with the recommended static site generator. In this way, we won't have to spend the time to write two plugins.
>
> I agree that we need to keep the big picture in mind and be forward looking. Also, I'd really like to avoid having to rewrite mounds of templates if we change the templating engine in the future. Using plain markup seems the best way forward for this. I hope my proposal can achieve this, as well as minimize the resource cost of evaluation.
>
> Let me know what you think.
>
> Thanks
> Justin
>
> On Jan 28, 2014, at 2:25 PM, Colin Clark <colinbdclark at gmail.com> wrote:
>
>>
>> On Jan 28, 2014, at 11:19 AM, Justin Obara <obara.justin at gmail.com> wrote:
>>
>>> "Why Weld?" is a good question. The simple answer is that it doesn't require any special syntax mixed in with the markup. This allows for clean templates that are valid markup. Which fits with our philosophies in Infusion and will be an easier transition if we switch to an internally made rendering system some time in the future.
>>>
>>> That being said, since none of them support it directly and we can write plugins for all of them, maybe we can defer this to later and just start wtih Jade for our evaluation.
>>
>> As a community, we have been dedicated to exploring alternatives to the “all mixed together” model of templating that is the prevailing style inherited from PHP. We should continue to pursue this value of unobtrusiveness and separation of the architectural layers with the tools we use for our own work.
>>
>> Writing a plugin for Weld templates will also be an excellent opportunity to verify the flexibility of the options we are considering. Keep in mind that within the next year or so, we will have our new Renderer available, and will undoubtedly want to integrate it into whatever solution we end up choosing. Let’s not loose sight of the big picture while choosing shorter-term technologies to use in our community.
>>
>> I hope this helps clarify,
>>
>> Colin
>
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
>